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PREFACE 


This  document  contains  the  proceedings  from  the  Defense  Modeling  and 
Simulation  Office  (DMSO)  Information/Data  Base  Task  Group  (I/DBTG)  meetings 
held  at  the  Institute  for  Defense  Analysis  (IDA)  during  the  week  of  February  14- 
18,  1994.  It  also  contains  the  notes  from  two  previous  DMSO  I/DB  Task  Group 
meetings  held  March  4-5,  1993  and  July  28-29,  1993  which  were  distributed  to  the 
I/DB  membership  through  surface  and  electronic  mail. 

The  work  described  here  was  performed  for  the  Defense  Modeling  and  Simulation 
Office  as  part  of  its  initiative  to  strengthen  the  use  of  simulation  and  modeling 
throughout  DoD.  RAND’s  participation  in  this  effort  was  performed  for  the 
Director,  Defense  Modeling  and  Simulation  Office  within  the  Applied  Science  and 
Technology  Program  of  RAND’s  National  Defense  Research  Institute  (NDRI),  a 
federally  funded  research  and  development  center  sponsored  by  the  Office  of  the 
Secretary  of  Defense  and  the  Joint  Staff. 

This  work  should  be  of  interest  to  those  working  in  the  areas  of  interoperability  of 
information  systems,  information  resource  management  (IRM),  data  dictionary 
systems,  resource  directories,  data  modeling  and  use  of  IDEF  tools,  complex  data, 
data  verification,  validation,  and  certification  (W&C),  data  quality,  and 
assessment  of  data  management  technology. 
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SUMMARY 


This  document  contains  the  proceedings  from  the  Defense  Modeling  and 
Simulation  Office  (DMSO)  Information/Data  Base  (I/DB)  Task  Group  meetings 
held  at  the  Institute  for  Defense  Analysis  (IDA)  during  the  week  of  February  14- 
18,  1994.  It  also  contains  the  notes  from  two  previous  DMSO  I/DB  Task  Group 
meetings  held  March  4-5,  1993  and  July  28-29,  1993  which  were  distributed  to  the 
I/DB  membership  through  surface  and  electronic  mail. 

The  DMSO  I/DB  Task  Group  was  formed  in  January  1992  from  the  Information 
Technology  and  Data  Base  Technology  working  groups  who  met  from  August  1991 
through  December  1991  to  perform  technology  assessments  in  support  of  the 
DMSO  Master  Plan.  The  original  task  groups  were  mainly  composed  of 
representatives  from  federally  funded  research  and  development  centers 
(FFRDCs).  An  earlier  document,  “Database  Technology  Activities  and 
Assessment  for  Defense  Modeling  and  Simulation  Office  (DMSO)  (August  1991  - 
November  1992),  RAND  MR-130-ACQ,  1994,  describes  the  activities  from  August 

1991  —  November  1992.  This  document  describes  the  activities  from  November 

1992  through  February  1994. 

The  main  and  continuing  purpose  of  the  I/DB  Task  Group  is  to  address  issues 
affecting  the  interoperability,  sharing,  and  reuse  of  databases  and  models 
throughout  the  Modeling  and  Simulation  (M&S)  community.  The  DoD  Corporate 
Information  Management  (CIM)  initiative  continues  to  address  many  of  the  data 
related  needs  of  the  M&S  community  but  not  all.  It  is  important  for  the  M&S 
community  to  be  aware  of  the  data  needs  not  being  met  by  CIM  and  unlikely  to  be 
met  by  commercial  or  other  DoD  means.  These  data  needs  should  be  addressed  by 
the  M&S  community.  It  is  critical  that  the  I/DB  Task  Group  continue  to  monitor 
CIM  activities  and  help  DMSO  develop  compatible  M&S  guidelines  and  procedures 
whenever  possible  while  pointing  out  possible  incompatibilities  with  CIM. 

The  I/DB  Task  Group  is  currently  co-chaired  by  Dr.  Chien  Huo  from  the 
DISA/JIEO  Center  for  Standards  who  is  working  with  the  DMSO  to  carry  out 
their  data  administration  and  standards  program,  and  by  Ms.  Iris  Kameny  from 
RAND  who  led  the  first  Data  Base  Technology  Working  Group  and  has  been 
supporting  DMSO  since  1991  in  their  data  related  activities.  Dr.  Huo  and  Ms. 
Kameny  are  working  with  CDR  Gary  Misch  (DMSO)  and  with  LTC  Jerry 
Wiedewitsch,  the  Deputy  and  Technical  Director  of  DMSO. 

The  I/DB  Task  Group  has  grown  from  around  a  dozen  members  at  its  inception  to 
over  100  members  today.  It  consists  of  people  from  the  Services,  Joint  Staff,  DoD 
agencies,  Intelligence  Community,  ARPA,  NIST,  NASA,  OSD,  FFRDCs,  and 
contractors  working  on  government  M&S  programs.  The  I/DB  Task  Group  meets 
approximately  every  four  months  (except  for  a  meeting  in  the  fall  of  1993  which 
was  replaced  by  the  first  MORS  Mini-Symposium  on  Simulation  Data).  The  I/DB 
Task  Group  has  created  several  Task  Forces  each  of  which  has  co-chairs  who  are 
predominantly  from  the  Services  and  the  Joint  Staff.  The  I/DB  specific  Task 
Forces  meet  more  frequently  as  needed. 
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Because  of  its  size,  the  I/DB  Task  Group  has  become  more  of  an  information 
exchange  forum  for  the  data  suppliers  to  the  M&S  community  than  an  action 
body.  Members  make  requests  for  information  mainly  about  data  standards, 
repositories,  directories,  data  quality,  complex  data,  etc.  and  the  meeting  agenda 
is  developed  according  to  the  expressed  needs.  In  addition,  I/DB  members  and 
others  are  invited  to  brief  about  their  M&S  projects,  database  environments  and 
centers  to  support  M&S,  and  non-M&S  oriented  databases  and  systems  used  by  the 
M&S  community.  This  exchange  has  been  very  helpful  in  getting  different 
organizations  to  know  each  other  and  work  together  toward  exchanging  and 
reusing  databases  rather  than  developing  redundant  databases.  Over  the  past 
year,  the  I/DB  community  has  begun  to  function  as  a  community  of  people  coming 
together  to  solve  common  problems. 

Accomplishments  of  the  I/DB  include: 

—  Developing  the  M&S  Information  System  at  DTIC  and  the  I/DB  portion 
on  an  internet  gopher  server  at  RAND 

—  Development  of  initial  data  models  and  standards  for  a  Database 

Directory  and  a  Model  and  Simulation  Directory  (each  can  be  used  as  a 
“standard”  core  by  different  organizations  enabling  sharing  of  directory 
information  across  the  M&S  community) 

—  Carrying  out  an  initial  pilot  study  of  modeling  complex  derived  data 
using  the  Army  TRAC  weapon  performance  data  (e.g.,  probability  hit, 
kill)  and  sharing  the  lessons  learned  with  the  community 

—  Development  of  a  methodology  to  build  subject  area  information  data 
models  through  reverse  engineering,  and  training  organizations  in 
carrying  out  these  activities  utilizing  IDEF  modeling  techniques  (the 
Joint  Data  Base  Elements  project) 

—  Supporting  DMSO  in  becoming  the  delegated  Functional  Data 
Administrator  (FDAd)  for  the  M&S  functional  area 

—  Currently  developing  a  Data  Administration  Strategic  Plan  (DASP) 

—  Being  instrumental  in  getting  CIM  to  address  complex  data  and  derived 
data  in  their  new  Defense  Information  Repository  System  data  model 

To  expedite  work  in  data  related  support  for  M&S,  the  I/DB  Task  Group  has 
started  three  Task  Forces  for  accomplishing  work  in  the  areas  of  Complex  Data, 
Data  Standards  and  Data  Verification,  Validation,  and  Certification  (W&C). 

Each  of  these  groups  met  for  a  day  during  the  week  of  February  14-18.  Specific 
tasks  being  addressed  are: 

—  Develop  guidelines  for  data  W&C  including  definition  of  a  certification 
profile  that  will  describe  the  quality  of  a  dataset  and  create  an  audit  trail 
for  derived  and  aggregated  data 


Develop  a  directory  and  guidelines  and  define  responsibilities  for 
authoritative  data  sources  and  ways  of  identifying/specifying 
authoritative  sources.  Define  the  roles  of  M&S  data  centers  that  receive 
data  from  authoritative  sources  and  prepare  it  for  input  to  models 

Define  and  develop  an  M&S  repository  needed  by  DMSO  to  maintain 
such  objects  as  directories,  data  models,  process  models,  data 
standards,  etc. 

Define  and  develop  a  taxonomy  or  index  (e.g.,  keywords,  phrases)  to 
support  access  to  models,  simulations,  and  databases  for  browsing  and 
reuse 

Develop  a  categorization  of  complex  data  types  and  a  guideline  as  to  how 
to  model  and  develop  complex  data  standards  that  may  require 
extensions  to  the  CIM  data  standardization  process  and  the  IDEF1X 
methodology  (where  complex  data  includes  derived  data,  rules,  objects, 
networks,  images,  voice,  documents,  etc.) 

Address  the  security  threat  resulting  from  the  use  of  aggregation  and 
inference  techniques  applied  to  the  large  M&S  data  collections 
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1.  INTRODUCTION 


PURPOSE 

The  purpose  of  this  document  is  to  provide  the  proceedings  of  the  February  14-18 
Defense  Modeling  and  Simulation  Office  (DMSO)  Information/Data  Base  (I/DB) 
Task  Group  meeting  to  members,  to  provide  information  to  people  who  wish  to 
participate  in  the  I/DB  Task  Group,  and  those  with  an  interest  in  data  activities 
related  to  modeling  and  simulation. 

BACKGROUND 

In  1991  the  Deputy  Secretary  of  Defense  instituted  a  major  new  initiative  to 
strengthen  the  application  of  modeling  and  simulation  (M&S)  in  the  DoD.  Its 
purpose  is  to  promote  the  effective  and  efficient  use  of  M&S  in  joint  education, 
training  and  military  operations,  research  and  development,  test  and  evaluation, 
analysis,  and  production  and  logistics  by:  (1)  establishing  OSD  cognizance  and 
facilitating  coordination  among  DoD  M&S  activities;  (2)  promoting  the  use  of 
interoperability  standards  and  protocols  where  appropriate;  and  (3)  stimulating 
joint  use,  high  return  on  M&S  investment.  Achievement  of  these  goals  requires 
the  development  and  implementation  of  a  DoD  M&S  policy,  establishment  of  a 
DoD-wide  management  structure  to  coordinate  joint  M&S  activities  and 
requirements,  and  the  formulation  and  implementation  of  a  long  range  M&S  joint 
investment  strategy. 

A  DoD  Executive  Council  for  Modeling  and  Simulation  (EXCIMS)  consisting  of 
DoD  Component  representatives  was  established  as  a  board  to  advise  the 
USD(A&T)  on  M&S  policy,  initiatives,  M&S  standards,  and  investments  for 
improving  current  M&S  capability  and  promising  M&S  advanced  technologies. 
The  Defense  Modeling  and  Simulation  Office  (DMSO)  was  established  to  serve  as 
an  executive  secretariat  for  the  EXCIMS  and  to  provide  a  full-time  focal  point  for 
information  concerning  DoD  M&S  activities.  The  DMSO  promulgates  USD(A&T)) 
directed  M&S  policy,  initiatives,  and  guidance  to  promote  cooperation  among  DoD 
Components  to  maximize  M&S  efficiency  and  effectiveness. 

To  carry  out  its  functions  and  develop  a  master  plan,  the  DMSO  enlisted  the  help 
of  several  Federally  Funded  Research  and  Development  Centers  (FFRDCs).  A 
number  of  functional  and  technology  working  groups  were  established  to 
determine  the  M&S  needs  and  to  evaluate  the  state-of-the-art  with  respect  to  those 
needs.  The  functional  groups  are:  education,  training  and  military  operations; 
research  and  development;  test  and  evaluation;  analysis;  and  production  and 
logistics.  The  technical  working  groups  are:  experiments;  architecture, 
standards,  and  interoperability;  methodology/applications;  information; 
networking;  computers;  software;  graphics;  databases;  instrumentation; 
behavior;  and  environment. 
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As  a  result  of  initial  activities,  the  Information  Technical  Working  Group  (ITWG) 
began  to  develop  plans  and  design  of  a  DMSO  Information  System  to  facilitate 
coordination  among  DoD  M&S  activities.  The  Database  Technology  Working 
Group  (DBTWG)  identified  three  efforts  found  critical  to  M&S  needs:  need  for 
directories,  dictionaries,  encyclopedias,  and  repositories  to  support  timely  and 
cost  effective  access  to,  acquisition  of,  and  validation  of  external  and  derived 
databases;  interoperability,  data  integrity  and  consistency  across  distributed 
databases  and  simulations;  and  M&S  community  objective  assessment  of  data 
management  products  such  as  relational  DBMSs.  COL  Jim  Shiflett  of  DMSO, 
asked  that  a  special  task  group  be  formed  from  the  ITWG  and  the  DBTWG  to 
address  the  DMSO  Information  System  in  coordination  with  the  first  DBTWG 
identified  need  for  directories,  dictionaries,  etc.  The  DMSO  I/DB  Task  Group  was 
formed  in  January  1992  from  the  Information  Technology  and  Data  Base 
Technology  working  groups.  The  document  “Database  Technology  Activities  and 
Assessment  for  Defense  Modeling  and  Simulation  Office  (DMSO)  (August  1991 — 
— November  1992),  RAND  MR-130-ACQ,  1994  describes  I/DB  Task  Group  activities 

from  August  1991 - November  1992.  This  document  describes  the  activities 

from  November  1992  through  February  1994. 

THE  I/DB  TASK  GROUP 

The  I/DB  Task  Group  is  currently  co-chaired  by  Dr.  Chien  Huo  from  the 
DISA/JIEO  Center  for  Standards  who  is  working  with  the  DMSO  to  carry  out 
their  data  administration  and  standards  program,  and  by  Ms.  Iris  Kameny  from 
RAND  who  led  thrt  first  Data  Base  Technology  Working  Group  and  has  been 
supporting  DMSO  since  1991  in  their  data  related  activities.  Dr.  Huo  and  Ms. 
Kameny  work  with  CDR  Gary  Misch  (DMSO)  and  with  LTC  Jerry  Wiedewitsch, 
the  Deputy  and  ""  chnical  Director  of  DMSO. 

The  I/DB  Task  Group  has  grown  from  around  a  dozen  members  at  its  inception  to 
over  100  members  today.  It  consists  of  people  from  the  Services,  Joint  Staff,  DoD 
agencies,  Intelligence  Community,  ARPA,  NIST,  NASA,  OSD,  FFRDCs,  and 
contractors  working  on  government  M&S  programs.  The  I/DB  Task  Group  meets 
approximately  every  four  months  (except  for  a  meeting  in  the  fall  of  1993  which 
was  replaced  by  the  first  MORS  Mini-Symposium  on  Simulation  Data).  The  I/DB 
Task  Group  has  created  several  Task  Forces  each  of  which  has  two  or  more  co¬ 
chairs  who  are  predominantly  from  the  Services  and  the  Joint  Staff.  The  I/DB 
specific  Task  Forces  meet  more  frequently  as  needed. 

Because  of  its  size,  the  I/DB  Task  Group  has  become  more  of  an  information 
exchange  forum  for  the  data  suppliers  to  the  M&S  community  than  an  action 
body.  Members  make  requests  for  information  mainly  about  data  standards, 
repositories,  directories,  data  quality,  complex  data,  etc.  and  the  meeting  agenda 
is  developed  according  to  the  expressed  needs.  In  addition,  I/DB  members  and 
others  are  invited  to  brief  about  their  M&S  projects,  database  environments  and 
centers  to  support  M&S,  and  non-M&S  oriented  databases  and  systems  used  by  the 
M&S  community.  This  exchange  has  been  very  helpful  in  getting  different 
organizations  to  know  each  other  and  work  together  toward  exchanging  and 
reusing  databases  rather  than  developing  redundant  databases.  Over  the  past 
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year,  the  I/DB  community  has  begun  to  function  as  a  community  of  people  coming 
together  to  solve  common  problems. 

OBJECTIVES  OF  THE  I/DB  TASK  GROUP 

The  broad  objective  of  the  DMSO  I/DB  Task  Group  is  to  support  DMSO  in 
promoting  the  interoperability,  sharing,  and  reuse  of  databases  and  models 
throughout  the  Defense  M&S  community.  To  accomplish  this  goal  requires  data 
and  model  administration  policies,  procedures,  standards,  and  supporting  tools 
compatible  with  those  of  CIM  and  the  Services.  It  also  requires  access  to 
information  throughout  the  M&S  community  about  what  is  happening  as  well  as 
information  about  the  existence  and  availability  of  models  and  simulations  and 
the  data  they  need.  Of  critical  concern  to  the  community  is  the  quality  of  the 
models  and  simulations  as  well  as  the  data  they  use  and  generate. 

Current  Status  In  Meeting  Objectives 

The  data  administration  objectives  are  being  addressed  through  the  recent 
delegation  of  M&S  functional  area  data  administration  responsibilities  to  DMSO. 
DMSO  is  now  the  Functional  Data  Administrator  (FDAd)  for  M&S  and  is 
developing  its  first  Data  Administration  Strategic  Plan  (DASP).  More  attention 
will  be  paid  by  CIM  to  M&S  data  needs  now  that  there  is  an  acting  M&S  FDAd. 

Complex  Data.  One  reason  this  has  been  an  important  accomplishment  is 
because  the  M&S  community  through  the  I/DB  has  recognized  the  lack  of 
attention  in  the  CIM  community  to  data  standards  for  scientific  and  technical 
data.  Much  M&S  data  is  not  atomic  single  concept  data  addressed  by  the  CEM 
data  standardization  process  (in  accord  with  DoD  8320.1-M-l)  but  is  complexly 
derived  (e.g.,  probability  hit,  kill),  or  structurally  complex  (e.g.,  a  road  network, 
an  object-oriented  engineering  view  of  a  weapon  system),  or  multimedia  data 
(e.g.,  images,  graphics,  voice),  or  conceptually  complex  (e.g.,  rules,  operation 
orders)  data.  An  I/DB  task  is  to  categorize  complex  data  and  develop  better  ways 
to  model  and  standardize  it  so  it  can  be  shared  and  reused  within  the  M&S 
community.  Just  recently,  the  I/DB  has  begun  working  with  the  CIM  Defense 
Information  Repository  System  (DIRS)  project  which,  at  I/DB  recommendation,  is 
including  complex  and  derived  data  in  its  data  model.  This  project  is  addressing 
future  needs  of  DoD  and  offers  an  opportunity  to  get  M&S  data  standards  needs 
included  in  future  DoD  standards. 

Support  for  Data  Standards.  The  Joint  Data  Element  Interoperability  (JDBF-) 
project  sponsored  by  DMSO  has  developed  a  methodology  (documented  in  t 
Military  Handbook)  to  build  subject  area  information  models  through  reverse 
engineering  of  existing  databases  using  IDEF1X  tools.  This  is  to  be  extended  to 
support  the  development  of  data  standards.  The  JDBE  project  is  available  to  M&S 
data  projects  for  IDEF  training  and  help  in  developing  their  data  models. 

M&S  Repository.  The  I/DB  also  has  a  repository  group  that  will  be  determining 
the  structure  and  functions  required  for  an  M&S  reposit  iry  to  handle  the 
directories,  data  and  process  models,  and  data  standards  being  developed  by  the 
M&S  community.  Important  questions  about  what  should  be  maintained  in  the 
repository  include:  Should  the  repository  store  and  maintain  sharable  databases 
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and  simulation  models  after  projects  are  completed  and  there  is  no  other  place  to 
maintain  them?  Should  DMSO  support  the  maintenance  of  repositories  by 
Services  and  other  organizations  rather  than  at  DMSO?  How  should  different 
repositories  exchange  information?  Will  the  community  need  a  directory  system 
of  repositories  and  their  wares?  Of  server  systems  and  their  services?  Should  the 
M&S  Information  System  act  as  a  server  frontend  to  users  to  handle  their 
requests  by  searching  other  servers  and  repositories? 

M&S  Information  System.  The  M&S  Information  System  was  developed  to  meet 
the  M&S  community  needs  for  access  to  information  and  it  has  become 
operational  over  the  past  year.  An  I/DB  portion  of  the  system  is  maintained  on  an 
internet  gopher  server  at  RAND. 

Directories.  One  of  the  original  M&S  community  requests  (from  all  of  the 
functional  working  groups)  was  for  directories  to  M&S  databases  and  models  and 
simulations.  This  is  being  addressed.  Data  models  for  both  directories  have  been 
developed  and  are  undergoing  community  consensus  with  plans  for  speedy 
implementation.  These  directories,  various  M&S  data  centers  and  M&S  program 
reuse  libraries  need  a  taxonomy  or  index  (e.g.,  key  words  or  phrases)  to  enable 
access  to  the  stored  objects  and  information  in  a  user  friendly  way  for  browsing 
and  reuse.  Another  I/DB  group  is  working  on  developing  such  a  taxonomy  which 
will  be  available  across  the  community. 

Data  Verification,  Validation  &  Certification.  The  M&S  community  has 
established  guidelines  for  verification,  validation,  and  accreditation  (W&A)  of 
M&S.  The  I/DB  community  is  in  the  process  of  developing  guidelines  for 
verification,  validation,  and  certification  (W&C)  of  data  and  will  be  working 
closely  with  the  W&A  Task  Force.  It  will  be  defining  a  certification  profile  that 
will  describe  the  quality  of  a  database  including  the  types  of  verification  and 
validation  tests  performed  on  the  data.  The  profile  would  be  available  to  all  the 
potential  M&S  users  of  the  database.  It  will  enable  them  to  understand  what  data 
is  contained  in  the  database,  its  quality,  and  aid  them  in  deciding  if  the  quality  is 
sufficient  for  the  task  at  hand.  If  the  quality  is  insufficient,  then  the  profile  would 
aid  them  in  making  cost/benefit  decisions  about  achieving  the  data  quality  they 
desire. 

CIM  has  recently  become  interested  in  promoting  data  quality  within  the  DoD. 

The  main  difference  between  their  data  quality  program  and  this  I/DB  effort 
appears  to  be  that  they  are  engaged  in  establishing  data  quality  standards  within 
DoD  while  the  I/DB  is  trying  to  develop  a  way  to  describe  the  quality  of  a  database 
independent  of  a  quality  standard.  Some  M&S  databases  (e.g.,  intelligence  force 
assessments,  futures)  are  by  their  nature  incomplete,  of  variable  probability  of 
belief,  etc. — this  is  the  type  of  information  (as  well  as  other  kinds  of  data)  that  will 
be  captured  in  the  profile. 

Authoritative  Data  Sources.  Where  the  data  standards  effort  is  dealing  with  the 
creation  and  management  of  data  about  data  (metadata)  to  enable  data  sharing,  a 
part  of  the  W&C  task  effort  addresses  the  owners  of  the  “real”  data.  They  will  be 
developing  a  directory  and  guideline  for  authoritative  sources  of  M&S  data 
including  specifying  what  their  responsibilities  are  to  the  rest  of  the  M&S 
community.  Part  of  the  task  is  to  determine  how  authoritative  sources  will  be 
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identified  and  selected.  Another  part  of  the  task  is  to  define  the  roles  of  the  M&S 
data  centers  that  take  data  from  sources  and  prepare  it  for  input  to  a  specific  set  of 
models. 

Database  Security.  An  additional  area  of  interest  to  the  I/DB  community  is  the 
potential  security  threat  resulting  from  the  use  of  aggregation  and  inference 
techniques  applied  to  the  large  M&S  data  collections  as  well  as  interest  in  multi¬ 
level  security. 

ORGANIZATION  AND  STRUCTURE  OF  THIS  DOCUMENT 


This  document  contains  the  proceedings  from  the  Defense  Modeling  and 
Simulation  Office  (DMSO)  Information/Data  Base  (I/DB)  Task  Group  meetings 
held  at  the  Institute  for  Defense  Analysis  (IDA)  during  the  week  of  February  14- 
18,  1994.  It  also  contains  the  notes  from  two  previous  DMSO  I/DB  Task  Group 
meetings  held  March  4—5,  1993  and  July  28-29,  1993  which  were  distributed  to  the 
I/DB  membership  through  surface  and  electronic  mail. 

Section  1  contains  the  table  of  contents.  The  agenda  and  list  of  attendees  for 
each  meeting  can  be  found  in  the  Section  reporting  on  that  meeting.  - 

Section  2  contains  the  highlights  of  the  I/DB  Task  Group  meetings  during 
the  week  of  February  14-18, 1994. 

Section  3  contains  notes  for  the  main  I/DB  meeting  held  on  February  16-17, 
1994  which  included  an  update  on  DMSO  happenings,  reports  from  other 
organizations,  data  administration,  standardization  and  modeling 
activities,  progress  on  the  database  and  M&S  directories,  and  reports  from 
various  M&S  projects.  The  briefing  charts  from  the  I/DB  meeting  are  in 
Appendix  A. 

Section  4  contains  notes  for  the  Data  W&C  Task  Force  Meeting  held  on 
February  14,  1994.  The  briefing  charts  from  this  meeting  are  in  Appendix 

B. 

Section  5  contains  notes  for  the  Data  Standards  Task  Force  Meeting  held  on 
February  17,  1994.  There  were  no  briefing  charts  from  this  meeting. 

Section  6  contains  notes  for  the  Complex  Data  Task  Force  Meeting  held  on 
February  18,  1994.  The  briefing  charts  from  this  meeting  are  in  Appendix 

C . 

Appendix  D  contains  the  notes  from  the  5th  I/DB  Workshop,  held  March  4- 
5,  1993  at  IDA.  These  notes  were  previously  distributed  by  surface  mail  and 
electronic  mail. 

Appendix  E  contains  the  notes  from  the  6th  I/DB  Workshop,  held  July  28- 
29,  1993  at  IDA.  These  notes  were  previously  distributed  by  surface  mail 
and  electronic  mail. 
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Appendix  F  contains  an  acronym  list. 
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2.  I/DB  TASK  GROUP  MEETING  HIGHLIGHTS 
FEBRUARY  14-18, 1994. 


This  I/DB  meeting  was  different  from  the  previous  ones  in  that  we  had  Task  Force 
meetings  on  the  days  before  and  after  the  I/DB.  The  highlights  of  the  I/DB  and  the 
new  Task  Force  organizations  are  shown  below. 

DMSO  Deputy  Director  Jerry  Wiedewitsch  stressed  the  importance  of  data  related 
efforts  to  the  DMSO  goal  of  promoting  the  efficient  and  effective  use  of  M&S  at  the 
Joint  and  DoD  levels.  About  50%  of  DMSO  funding  goes  to  the  support  of 
databases,  tools  and  methodologies  and  support  for  these  areas  is  expected  to 
continue  at  the  same  rate.  He  thanked  the  I/DB  community  for  their  enthusiasm, 
effort  and  support. 

Howard  Haeker  (Army/TRAC)  has  taken  responsibility  for  DIS  data  standards 
which  will  include  applying  data  standards  across  data  used  in  models  and 
PDUs. 

Jeff  Wolfe  (JIEO/CIM)  discussed  the  Defense  Information  Repository  System 
(DIRS)  project  which,  if  accepted,  will  be  a  single  logical  repository  incorporating 
products  from  the  four  activities  of  functional  process  improvement,  data 
administration,  software  reuse,  and  software  engineering.  An  important  point 
for  I/DB  is  that  he  has  incorporated  the  concept  of  complex  data  into  his  core  data 
model  and  has  asked  for  I/DB  help  in  reviewing  the  data  model  including 
additional  specificity  of  complex  data.  (The  I/DB  community  shared  its  views  on 
complex  data  with  Wolfe  last  year.) 

Mike  Rybacki  (Army  Model  and  Simulation  Management  Office),  on  request, 
brought  Jim  Glymph  (Army  data  modeler)  to  clarify  the  Army  position  on  data 
standards  with  respect  to  how  an  M&S  project  could  be  responsive  to  AR25-9  and 
DoD  8320.1-M-l  simultaneously.  There  is  still  an  open  issue  of  missing  guidance 
from  JIEO/CIM  as  to  the  process  to  be  followed  by  an  M&S  project  in  submitting 
data  standards  proposals  for  nomination  to  the  DoD  DDRS.  Specifically,  whether 
this  should  be  done  through  the  Component  Data  Administrator  or  through  the 
M&S  Functional  Data  Administrator. 

Jack  Teller  (DMA)  shared  DMA’s  initial  step  in  developing  a  spatial  IDEF1X  data 
model  with  JIEO/CIM  support  and  their  future  plans.  This  addresses  a  critical 
I/DB  recognized  need  for  data  standards  for  MC&G  data  and  was  on  the  Complex 
Data  Task  Force  list  as  a  high  priority  pilot  study.  The  Complex  Data  Task  Force 
will  continue  to  track  this  work  in  detail. 

The  I/DB  community  showed  much  interest  in  active  review  of  the  M&S  directory 
data  model  and  IDA’s  prototype  implementation  plans  since  many  need  their  own 
M&S  directories  and  want  to  build  them  from  a  common  data  model.  The  next 
review  meeting  should  be  held  shortly. 
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There  was  much  positive  feedback  to  Chien  Huo  and  Iris  Kameny  from  I/DB 
members  on  the  importance  of  the  M&S  project  briefs.  Knowing  who  is  doing 
what  is  leading  to  plans  for  data  sharing  and  data  exchange. 

Duane  Hufford  (consultant  for  JIEO/CIM)  presented  a  draft  paper  to  the  Complex 
Data  Task  Force  (CDTF)  on  complex  data  categorization  and  IDEF1X  methods  for 
data  modeling  of  complex  data.  Members  of  the  CDTF  will  be  reviewing  the  paper 
and  getting  comments  back  to  the  author  and  Hufford  has  agreed  to  be  a  member 
of  the  complex  data  categorization  task. 

HIGHLIGHTS  OF  NEW  TASK  FORCE  MEETINGS 

Three  new  Task  Forces  held  meetings  during  the  week  of  the  main  I/DB  meeting. 
It  was  the  second  meeting  for  the  Complex  Data  Task  Force  and  the  first  meetings 
for  the  Data  Standards  and  W&C  Task  Forces  both  of  which  resulted  from  the 
November  1993  MORS  SIMDAT  working  group  recommendations. 

The  Data  Verification,  Validation,  and  Certification  Task  Force  organized  two 
subgroups: 

Guidelines  for  Data  W&C  (co-chairs  Bob  Hartling  (Navy)  and  Mark  Ralston 
(Army)):  a  major  task  will  be  to  define  a  certification  profile  for  a  database  that 
will  describe  its  data  quality  characteristics  including  verification  and  validation 
methods  used.  The  profile  will  be  necessary  for  database  certification. 

Authoritative  Data  Sources  and  Data  Centers  (co-chairs  Bill  Dunn 
(Army/AMSMO)  and  Mike  Hopkins  (CENTCOM)):  will  identify  Component 
authoritative  M&S  data  sources,  define  their  responsibilities  to  the  M&S 
community,  and  identify  and  define  the  roles  of  M&S  data  centers  that  get  data 
from  authoritative  sources  and  prepare  data  for  input  to  models. 

The  Data  Standards  Task  Force  made  specific  assignments  to  several  members 
and  identified  several  subgroups:  Coordination  of  Standards  Development,  Peter 
Valentine  (Army/JDBE);  Generic/Specific  Data  Models  and  Lessons  Learned,  Roy 
Scrudder  (Army/JDBE);  Reuse  Library  Framework  (RLF),  Luci  Haddad  (Army 
CCTT);  Coordination  of  Data  Standards  Across  and  Within  DoD,  Luci  Haddad 
(Army  CCTT);  Data  Model  Interchange  Standards,  Jim  Augins  (consultant  for 
Navy  ARMOR);  Repository  subgroup  led  by  Jim  Augins  (consultant  to  Navy 
ARMOR)  and  Peter  Valentine  (Army/JDBE);  and  Database  Security  subgroup  led 
by  Mike  Rybacki  (Army/AMSMO)  and  Twyla  Courtot  (MITRE). 

The  Complex  Data  Task  Force  identified  three  subgroups: 

Categorization  of  Complex  Data  (co-chairs  Len  Seligman  (Mitre)  and  Pete 
Valentine  (Army/JDBE)):  will  start  with  several  recent  categorization  attempts 
including  those  offered  in  Duane  Hufford’s  paper  and  the  DMA  data  modeling 
effort  and  try  to  feed  input  back  to  Jeff  Wolfe’s  DIRS  project. 

Pilot  studies  in  Complex  Data:  UTSS,  CCTT,  CENTCOM,  DIS  (and  keeping  up 
with  DMA  data  modeling),  Chien  Huo  will  coordinate  and  JDBE  will  support.  An 
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Army/TRAC  pilot  study  was  done  in  August  1993  and  reported  on  at  the  I/DB 
main  meeting. 

Taxonomy/Indexes  (co-chairs  Dan  Hogg  (JS/J8)  and  Iris  Kameny  (RAND))  (a 
subject  area  that  is  needed  by  the  Repositoiy  subgroup  and  the  database  and  M&S 
directories  as  well):  task  is  to  develop  indexes  to  be  used  for  accessing  information 
about  models  and  simulations  and  databases  in  DMSO  directories  as  well  as  in 
reuse  libraries.  Will  try  to  build  off  any  available  Component  indexes.  This  is  an 
important  subject  for  M&S  projects  such  as  CCTT  and  UTSS  as  well  as  non-M&S 
efforts. 

FUTURE  MEETINGS  OF  THE  TASK  FORCES/SUBGROUPS 

March  22,  1994,  Data  W&C  Guidance  Subgroup  Meeting  (at  IDA  Room  119). 
Goals  are:  (1)  finalized  versions  of  the  definitions  for  Data  W&C,  (2)  a  proposal 
for  conducting  joint  Data  W&C,  and  (3)  a  compilation  of  tools  and  techniques  for 
ensuring/measuring  data  quality. 

April  1,  1994,  Data  W&C,  Authoritative  Data  Sources  and  Data  Center  Subgroup 
milestone:  first  cut  to  compile  the  Services  and  Joint  Elements  efforts  to:  (1) 
provide  agency  names  and  responsibilities  of  the  authorized  (or  perceived  as 
authorized)  data  sources  as  necessary  according  to  mission  functionality  (e.g., 
terrain,  weather),  level  of  resolution  (e.g.,  engagement,  campaign,  theater),  and 
customer/applications.  What  criteria  constitute  an  authoritative  source?;  (2) 
provide  agency  names  and  responsibilities  of  data  centers  along  with  the 
customers  and  functionality  they  serve,  (3)  address  sharing  and  reusing  of  data 
between/among  these  data  sources  and  centers,  and  (4)  address  responsibilities  of 
data  customers. 

April  6-7,  Complex  Data  Categorization  Subgroup  meeting  at  IDA  to  get  initial 
consensus  on  complex  data  for  input  to  Jeff  Wolfe’s  DIRS  data  model. 

April  19, 1994,  W&C  Task  Force  Meeting  at  IDA  (0800 — 01700) 

April  20, 1994,  Data  Standards  Task  Force  Meeting  at  IDA  (0800 — 1700) 
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3.  I/DB  TASK  GROUP  MEETING  NOTES 

3.1  AGENDA 

WEDNESDAY,  FEBRUARY  16 

UPDATE  ON  DMSO  HAPPENINGS 

0800-0830  Welcome  and  DMSO  Update  Including  FY94  New  Project 
Starts:  LTC  Jerry  Wiedewitsch 

0830-0900  Overview  on  M&S  Data  Administration  Achievements  Dr.  Chien  Huo 
0900-0920  Report  from  M&S  Data  W&C  Task  Group:  Ms.  Iris  Kameny 
0920-0940  Report  from  M&S  Data  Standards  Task  Group:  Mr.  Howard  Haeker 
0940-1000  Report  from  M&S  Complex  Data  Task  Group:  Ms.  Iris  Kameny 
1030-1100  Report  on  DMSO  Standards  Infrastructure  Team:  Dr.  Bill  Flanigan 
1000-1030  BREAK 

REPORTS  FROM  OTHER  ORGANIZATIONS 

1100-1130  Report  from  MORS  SIMDAT  Mini-Symposium  and  DIS  Data 
Standardization:  Mr.  Howard  Haeker 

1130-1200  Update  from  TECNET  Information  System  for  the  Test  and 
Evaluation  Community:  Mr.  George  Hurlburt 

1200-1300  LUNCH 

DATA  ADMINISTRATION,  STANDARDIZATION  AND  MODELING  ACTIVITIES 
1300-1330  Update  on  DoD  Data  Model  (including  C2  Core  Model):  Mr.  Phil  Cykana 
1330-1400  Defense  Information  Repository  System  (DIRS)  Brief:  Mr.  Jeff  Wolfe 
1400-1430  JIEO  Update  on  C2  Data  Modeling:  Mr.  Stan  Plummer 
1430-1500  Report  on  IDEF  Users’  Group  Meetings  and  Issues:  Mr.  Peter  Valentine 

1500-1530  BREAK 

1530-1600  CCTT  Data  Standardization  and  Reuse:  Ms.  Luci  Haddad 
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1600-1630 

1630-1700 


0800-0845 

0845-0900 

0900-0930 

0930-1000 

1000-1030 

1030-1100 

1100-1130 

1130-1200 

1200-1300 

1300-1330 

1330-1400 

1400-1430 

1430-1500 

1500-1530 

1530-1600 

1600-1630 

1630-1700 


Report  on  TADS  Weapon  Performance  Data  Modeling:A/s.  Iris  Kameny 

Army  Modeling  and  Simulation  Management  Office 
Discussion  on  Data  Standards:  Mr.  Mike  Rybacki/Mr.  Jim  Glymph 

THURSDAY,  FEBRUARY  17 

PROGRESS  ON  DIRECTORIES 

Data  Model  for  M&S  Directory:  Mr.  Roy  Scrudder 

Security  CONOPS  for  Intelligence  Community  Catalog:  Dr.  John  Griffiths 

Discussion  of  Next  Steps  for  Database  Directory  and  Model  and 
Simulation  Directory  Implementation:  Dr.  Mike  Frame 

PROJECT  REPORTS 

JMASS  Briefing:  Capt  Bill  Cashman 

BREAK 

Update  on  Universal  Threat  Simulator  System  (UTSS) 

Project:  Mr.  Mike  Sarkovitz 

Update  on  Naval  Warfare  Tactical  Data  Base:  LCDR  John  Letaw 
DoD  Project  on  Spatial  Data  Standardization:  Dr.  Jack  Teller 
LUNCH 

AF  Studies  and  Analysis  Power  Projection  Data  Base  Project: 

Mr.  Stephen  Boyd 

Joint  Data  Base  Elements  Project:  Mr.  Steve  Matsuura 
Equipment  Characteristics  of  Data  Bases  (CCTT):  Mr.  Rob  Wright 
Update  on  CENTCOM  Conventional  Database  Project:  Mr.  Mike  Hopkins 
BREAK 

Experiences  in  Using  Project  2851  Data:  Dr.  Jed  Marti 
Navy  ARMOR  Project:  Mr.  Mike  Dabose 
Wrap-up:  Dr.  Chien  Huo/Ms.  Iris  Kameny 


3.2  ATTENDEE  LIST 
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3.3  UPDATE  OF  DMSO  HAPPENINGS 

LTC  Jerry  Wiedewitsch,  Deputy  and  Technical  Director  of  DMSO:  Welcome  and 
DMSO  Update 

LTC  Wiedewitsch  discussed  the  four  objectives  of  the  EXCIMS  investment 
strategy  for  achieving  the  goal  of  promoting  the  efficient  and  effective  use  of  M&S 
at  the  Joint  and  DoD  levels.  The  goals  are  to:  (1)  promulgate  standards  to  promote 
interoperability  of  the  components  of  the  M&S  environment;  (2)  support 
development  of  databases,  tools,  and  methodologies  for  community-wide  use;  (3) 
promote  development  of  a  communications  infrastructure  to  support  integration 
of  Joint  M&S  activities;  and  (4)  facilitate  community- wide  coordination  and 
information  sharing.  The  M&S  infrastructure,  as  the  foundation  which  will 
enable  and  support  meeting  the  DoD  objectives,  is  composed  of  four  categories: 
policy  and  management,  common  structural  definitions,  common-use  assets, 
and  community-wide  services. 

Jerry  stressed  the  importance  of  data  related  efforts  to  the  DMSO  goal  of  promoting 
the  efficient  and  effective  use  of  M&S  at  the  Joint  and  DoD  levels,  as  shown  by  the 
FY94  Focused  Call  in  the  M&S  Common  System  Support  area.  About  50%  of  DMSO 
funding  has  gone  to  the  support  of  databases,  tools  and  methodologies  and  support 
for  these  areas  is  expected  to  continue  at  the  same  rate.  Jerry  thanked  the  I/DB 
community  for  their  enthusiasm,  effort  and  support. 

Some  important  happenings  in  DMSO  since  the  last  I/DB  meeting  in  July 
included:  (1)  DoDD  5000.59,  Subject:  Modeling  and  Simulation  Management  was 
signed  January  4,  1994  and  is  available  through  the  M&S  Information  System;  (2) 
DMSO  has  been  delegated  the  responsibility  of  the  Functional  Data  Administrator 
for  Modeling  and  Simulation,  and  the  key  responsibility  rests  with  Dr.  Chien  Huo 
(supporting  DMSO  through  DISA/JIEO/CFS);  and  (3)  issuing  of  funds  for  the  FY 
94  projects  has  been  put  on  hold  temporarily  awaiting  DMSO  investment  guidance 
from  the  EXCIMS.  Dr.  Anita  Jones  has  said  that  DMSO  has  spent  two  years 
developing  consensus  and  standards  by  encouraging  community  "buy-in”  and  it  is 
now  time  to  support  the  broader  DoD  concerns  of  readiness,  infrastructure  and 
quality/value  added.  Dr.  Deutsch  has  given  authority  to  force  conformance  on 
M&S  data  standards  but  the  DMSO  community  is  working  hard  on  voluntary 
concurrence. 

There  are  four  DMSO  long  term  objectives:  (1)  seamlessly  link  live,  constructive 
and  virtual  simulations  on  demand  to  support  operational  readiness  of  forces,  (2) 
apply  M&S  more  broadly  and  with  increased  validity  throughout  DoD,  (3)  Provide 
authoritative  representations  with  appropriate  scalability,  fidelity  and 
granularity,  and  (4)  enable  interoperability  of  M&S  supporting  technologies. 

Jerry  went  into  some  detail  on  objective  #3,  which  directly  affects  the  I/DB 
community  activities.  The  considerations  for  FY95  investment  will  be  to:  orient 
on  M&S  objectives,  verify  infrastructure  elements,  use  infrastructure  as  a 
foundation,  focus  on  larger  DoD  concerns,  and  ensure  compliance  with  DoDD 
5000.59.  This  call  will  be  different  from  the  previous  ones,  the  schedule  is  not  yet 
determined,  but  DMSO  will  try  to  get  it  out  by  the  March-April  timeframe. 
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The  community  has  done  well  at  bringing  weapons  systems  into  the  simulations 
but  we  now  have  to  simulate  at  the  people/person  level  (e.g.,  dismounted 
combatants,  special  operations  forces,  etc.).  We  need  to  address  the  level  of  fidelity 
needed  with  respect  to  requirements,  doctrine,  techniques  and  look  at  how  we  can 
push  the  system  technology  to  the  individual  warrior  level.  We  need  to  be  able  to 
rapidly  generate  terrain  databases,  and  natural  asset  databases.  We  need  pilot 
programs  in  the  complex  data  area. 

Dr.  Chien  Huo:  Report  on  M&S  Data  Administration  Achievements 
We  have  finally  been  successful  in  getting  DDR&E  to  delegate  responsibility  to 
DMSO  to  act  as  the  Functional  Data  Administrator  (FDAd)  for  Modeling  and 
Simulation.  Dr.  Chien  will  be  carrying  out  this  role  and  asks  for  support  and 
cooperation  from  the  I/DB  community.  He  plans  to  use  the  I/DB  group  to  populate 
task  forces  to  address  particular  issues  and  problems,  and  to  be  responsive  to  the 
DMSO  focus  calls. 

The  main  data  administration  objectives  are  to  promote  the  efficiency,  validity  and 
interoperability  of  M&S  development  and  to  address  the  longer  term  DMSO 
objective  of  providing  authoritative  representations,  with  appropriate  scalability, 
fidelity,  and  granularity.  The  key  issues  are  in  the  areas  of:  data  standardization; 
data  sharing,  reuse  and  access;  data  verification,  validation,  and  certification 
(W&C);  life  cycle  management  of  data;  and  data  security.  Identified  M&S 
community  needs/efforts  are:  complex  data  standards;  M&S  repository;  Database 
and  M&S  Directories;  data  W&C;  M&S  taxonomy  (for  data/software  reuse); 
community  use  tool  development;  data  security;  and  nomenclature  and  symbology 
standards.  The  five  main  responsibilities  of  the  M&S  FDAd  are  to  (1)  implement  a 
M&S  data  administration  infrastructure  and  to  establish  community  consensus 
on  policies,  procedures  and  standards;  (2)  address  complex  data  standardization; 
(3)  establish  an  M&S  repository  and  develop  an  M&S  taxonomy.  Database 
Directory,  and  M&S  Directory;  (4)  identify  and  promulgate  data  administration 
methodology  and  tools;  and  (5)  facilitate  interchange  of  information  and  lessons 
learned.  Dr.  Huo  reviewed  current  project  activities  and  efforts  and  discussed 
ongoing  DMSO  supported  data  related  projects  many  of  which  were  reported  on 
later  in  the  I/DB  program. 

Ms.  Iris  Kameny:  Report  from  the  W&C  Task  Force 

Ms.  Kameny  reported  on  the  results  of  the  MORS  SIMDAT  Data  W&C  Working 
Group  November  16-18,  1993  and  on  the  first  meeting  of  the  W&C  Task  Force, 
February  14th.  The  MORS  Data  W&C  working  group  had  over  40  participants, 

10  papers  were  presented,  and  long  term  goals  of  data  W&C  and  issues  were 
discussed.  There  were  seven  findings:  (1)  need  for  a  W&C  group  to  address 
area;  (2)  need  for  policy,  procedures,  and  guidelines  for  data  W&C;  (3)  need 
concise  definition  of  terms;  (4)  W&C  needs  to  be  addressed  with  strong 
interaction  between  analysis  needs,  model  and  data;  (5)  need  to  collect  W&C  cost 
and  cost  benefit  data;  (6)  there  are  automation  tools  to  help  with  W&C;  and  (7) 
data  W&C  needs  to  deal  with  two  types  of  databases,  generic  (e.g.,  DMA,  DIA) 
and  M&S  supportive  (TADS,  CENTCOM  CFDB).  The  seven  findings  were 
combined  into  three  recommendations:  (1)  DMSO  pursue  establishment  of  an 
effort  to  further  address  these  issues;  (2)  need  for  DoD  to  develop  policy, 
procedures  and  guidelines  for  data  W&C  management  processes  applied  to  data 
sources  and  data  centers  to  enhance  affordability,  efficiency,  and  data 
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consistency;  and  (3)  define  Data  W&C  terms  and  promulgate  to  MORS 
community.  The  first  recommendation  was  carried  out  by  DMSO’s  establishment 
of  the  Data  W&C  Task  Force  that  will  be  addressing  recommendations  2  and  3. 
The  first  meeting  of  the  W&C  TF  on  February  14,  1993  continued  the  issue 
discussion  particularly  of  a  certification  profile  describing  the  quality  of  a  dataset 
and  definitions  for  the  terms  “verification,”  “validation”  and  “certification.”  Two 
subgroups  were  formed:  Guidelines  for  Data  W&C  (co-chairs  Bob  Ha_*tling 
(Navy)  and  Mark  Ralston  (Army)),  and  Authoritative  Data  Sources  and  Data 
Centers  (co-chairs  Bill  Dunn  (Army/AMSMO)  and  Mike  Hopkins  (CENTCOM)). 
The  report  of  the  first  W&C  Task  Force  meeting  is  given  in  Section  4  of  this 
report. 

Mr.  Howard  Haeker:  Report  from  M&S  Data  Standards  Task  Force 
Mr.  Haeker  gave  this  report  for  Ms.  Twyla  Courtot  who  led  the  MORS  SIMDAT 
Data  Standards  Working  Group  and  the  DMSO  Data  Standards  Task  Force  which 
met  for  the  first  time  on  February  15,  1994.  The  overarching  issues  from  the 
MORS  SIMDAT  meeting  were:  life  cycle  of  standards,  standards'  enforcement, 
and  information  about  standards.  Standards  begin  with  a  need,  they  continue  by 
people  conforming  and  using  them,  and  they  get  extended  by  usage/products  that 
add  value  to  the  standard  which  over  time  results  in  extension  to  the  standard. 

The  point  is  that  standards  should  be  regarded  as  extensible  and  evolutionary, 
changing  over  time.  Before  CIM,  there  was  no  strict  enforcement  of  standards 
rather  the  use  was  incentivized  by  cost  savings  through  interoperability  and 
reuse.  There  is  a  question  whether  this  can  work  or  if  strict  enforcement  may  be 
needed.  More  information  is  needed  by  the  M&S  community  about:  what 
standards  are  being  developed,  de  facto  and  official;  the  availability  of  tools, 
products  and  methods  supporting  various  standards;  and  the  M&S  community 
needs  and  priorities  for  standards.  The  MORS  SIMDAT  working  group 
recommendation  was  that  a  standards  group  be  formed  and  this  recommendation 
was  carried  out  by  formation  of  the  DMSO  Data  Standards  Task  Force. 


The  Data  Standards  Task  Force  made  specific  assignments  to  several  members 
and  identified  a  repository  subgroup:  Coordination  of  Standards  Development, 
Peter  Valentine  (Army/JDBE);  Generic/Specific  Data  Models  and  Lessons 
Learned,  Roy  Scrudder  (Army/JDBE);  Reuse  Library  Framework  (RLF),  Luci 
Haddad  (Army  CCTT);  Coordination  of  Data  Standards  Across  and  Within  DoD, 
Luci  Haddad  (Army  CCTT);  Data  Model  Interchange  Standards,  Jim  Augins 
(consultant  for  Navy  ARMOR);  Repository  subgroup  led  by  Jim  Augins 
(consultant  to  Navy  ARMOR);  and  Database  security  subgroup  led  by  Mike 
Rybacki  (Army/AMSMO)  and  Twyla  Courtot  (MITRE). 


Ms.  Iris  Kameny.  Report  from  the  M&S  Complex  Data  Task  Force 
Ms.  Kameny  reported  on  the  results  of  the  MORS  SIMDAT  Complex  Data 
Working  Group  November  16-18,  1993  (led  by  Mr.  Roy  Reiss)  and  on  the  first 
meeting  of  the  Complex  Data  Task  Force,  October  28,  1993  (led  by  Ms.  Iris 
Kameny).  Activities  having  to  do  with  complex  data  include: 


May  1993: 
August  1993: 
October  1993: 
November  1993: 


meeting  at  AMSMO 

pilot  study  TRAC  weapon  performance  data  model 
first  meeting  of  Complex  Data  Task  Force 
MORS  working  group  on  Complex  Data 
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February  1993:  second  meeting  of  Complex  Data  Task  Force 

The  definition  of  “complex  data’  from  the  MORS  Complex  Data  WG:  “complex 
data  is  data  which  contains  inherent  embedded  information.” 

The  long  term  goals  of  the  Complex  Data  Task  Force  (CDTF),  are  to  categorize 
complex  data  types,  and  to  develop  a  guideline  to  data  modeling  and 
standardization  of  complex  data  types  for  the  M&S  community.  In  the  near  term, 
several  activities  are  being  conducted:  (1)  a  subgroup  was  formed  to  address 
categorization  of  complex  data  co-chaired  by  Len  Seligman  (Mitre)  and  Pete 
Valentine  (Army/JDBE));  (2)  a  subgroup  to  deal  with  pilot  studies  in  complex  data 
was  formed  of  representatives  from  UTSS,  CCTT,  CENTCOM,  DIS,  and  DMA 
efforts  with  Chien  Huo  coordinating  and  JDBE  supporting;  (3)  a  subgroup  was 
formed  to  look  at  taxonomy/index  issues  co-chaired  by  Dan  Hogg  (JS/J8)  and  Iris 
Kameny  (RAND));  and  (4)  coordination  with  CIM  is  ongoing  with  the 
participation  of  several  CIM  people. 

Dr.  Bill  Flanagan:  Report  on  DMSO  Standards  Infrastructure  Team 
In  the  spring  of  1993,  COL  Ed  Fitzsimmons,  Director  of  DMSO,  chartered  ten 
Infrastructure  Task  Force  (ITF)  teams  (in  addition  to  the  I/DB):  architecture, 
behavioral  representation  (automated  forces),  C3I  M&S  interfaces,  DIS  testbeds, 
information  clearing  house  for  M&S,  instrumentation,  networks,  security, 
standards,  and  W&A.  ITF  missions  were  to:  identify  unaddressed 
infrastructure  needs  that  cut  across  the  M&S  community;  identify  shortfalls  and 
opportunities;  and  recommend  products/  processes/proposals  to  meet  the 
shortfalls. 

Bill  Flanigan  (DISA/JIEO/CFS)  and  Marv  Hammond  (IDA)  are  co-leaders  of  the 
Standards  Infrastructure  Task  Force  Team  (SIT).  The  SIT  vision  taken  from 
DoDD  5000.59  is  “To  facilitate  the  identification,  establishment,  acceptance,  and 
implementation  of  standards,  protocols,  and  other  appropriate  mechanisms  to 
promote  efficient  and  effective  interoperability,  open  systems,  and  the  reusability 
of  hardware,  software,  and  data  for  applications  of  M&S.  These  standards, 
protocols,  and  other  mechanisms  will  be  consistent  with  and  build  upon  current 
national,  federal,  DoD-wide,  and,  where  practical,  international  standards.”  The 
SIT  purpose  is  to  provide:  (1)  a  focal  point  for  guidance/leadership  for  standards  to 
DMSO  and  the  broader  M&S  community;  (2)  build  consensus  and  pro-actively 
foster  cost  reduction  through  defense  conversion  and  dual  use,  migration  to 
vendor-neutral  open  systems,  and  promotion  of  cultural  change  to  DIS  and 
related  environments;  (3)  publish  periodic  assessments  and  studies;  and  (4)  evolve 
a  “national  planner’s”  point  of  view  from  a  “city  planner’s”  point  of  view.  The  SIT 
membership  is  extensive,  consisting  of  representatives  from  defense  agencies, 
other  federal  departments,  FFRDCs,  intelligence  agencies,  joint  staff, 
manufacturing  associations,  medical  community,  NASA,  etc. 

Issues  and  shortfalls  (more  fully  described  in  SIT  Report  01-94  available  through 
the  M&S  Information  System)  includes:  lack  of  availability  of  standard  processes 
and  models  for  “complex”  data  and  “objects”;  lack  of  software  reuse  and  repository 
access;  uncoordinated  standards  development/use  within  and  between  DoD  and 
federal  components;  most  M&S  documentation  is  nonstandard/informal/non¬ 
existent;  existing  standards  lag  behind  time  frame  needs  of  M&S  community;  and 


19 


proliferation  of  nonstandard/non-interoperable  M&S  information  systems  across 
DoD  and  federal  components. 

The  Standards  Infrastructure  Task  Force  Team  (SIT)  recommendations  to  DMSO 
include:  investigate  lower-cost  alternatives  to  standardizing  M&S  data 
types/models;  identify/reduce/eliminate  non-standard,  redundant  data/object 
activities;  formally  adopt  a  standards’  framework  (suggested  DoD  Technical 
Architecture  Framework  for  Information  Management  (TAFIM));  ensure  DoD 
interests  are  represented  in  all  appropriate  nongovernment  standards  bodies; 
provide  automated,  expert  system  to  generate  hardware  and  software 
standards/standardization  profiles  for  program  managers;  and  counter 
heterogeneous  information  system  proliferation  by  promoting  seamless 
interoperability.  Latest  version  of  the  TAFIM  is  dated  22  June  1993  and  is 
available  through  the  Defense  Technical  Information  Center  (DTIC).  For  now,  if 
anyone  needs  a  standards  profile,  Flanagan  said  the  DISA/JIEO/CFS  has  one 
available.  He  stressed  that  we  need  a  way  to  automate  standardization,  a  way  to 
“COTS”  your  requirements,  possibly  an  interactive  question  and  answer  process. 

The  SIT  visionary,  high  level  road  map  for  M&S  is  being  reviewed  now.  A  review 
of  standards  activities  and  issues  involving  DMSO  projects  funded  in  FY94  is  also 
being  done,  and  SIT  is  furnishing  standards  language  for  DMSO’s  FY  1994—1995 
infrastructure  RFPs. 

Twyla  Courtot  (MITRE)  is  a  member  of  the  SIT  and  can  report  I/DB  activities  to 
the  SIT  and  report  back  to  the  I/DB  about  SIT  activities. 

Questions  and  Answers: 

There  seems  to  be  two  W&A  groups,  the  M&S  W&A  WG  and  the  Infrastructure 
W&A  Team. 

For  investigating  lower-cost  alternatives  to  standards  for  M&S  data  types,  it  was 
suggested  that  the  SIT  come  to  the  data  source  people  within  the  I/DB. 

A  question  was  asked  about  what  the  SIT  wanted  to  get  from  the  I/DB  (a  wall  or  a 
city)?  (I  wasn’t  clear  on  the  answer)  It  seemed  to  have  something  to  do  with  things 
that  were  not  in  the  Component’s  rice  bowls. 

Flanagan  said  the  SIT  will  have  two  tiers  of  members:  core  members  and  subject 
matter  experts  that  will  be  invited  to  participant  on  an  as-needed  basis. 

3.4  REPORTS  FROM  OTHER  ORGANIZATIONS 

Mr.  Howard  Haeken  Report  from  MORS  SIMDAT  Mini-Symposium  and  DIS 
Data  Standardization 

The  MORS  SIMDAT  Mini-Symposium  (November  16-18,  1993)  was  chaired  by 
Michael  Bauman  (TRAC)  and  the  technical  program  chair  was  Howard  Haeker 
(TRAC).  There  were  178  attendees,  109  were  government  and  69  were  from 
industry  and  academia.  Plenary  speakers  were:  Mr.  Walter  Hollis  (DUSA(OR)), 
Ms.  Belkis  Leong-Hong  (CIM,  DISA),  LTC  Jerry  Wiedewitsch  (DMSO),  and  Mr. 
Ed  Fitzsimmons,  Office  of  Science  and  Technology.  There  were  six  working 
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groups:  W&C,  Tools  and  Techniques,  Complex  Data,  Standards,  Research,  and 
Data  Suppliers  as  well  as  a  Synthesis  Group. 

Overarching  issues  from  the  Synthesis  Group  were  mainly  in  the  areas  of 
standards  and  W&C,  with  recommendations  to  form  new  groups  in  both  areas 
and  questions  as  to  who  pays  for  activities  in  both  of  these  areas,  and  how  do  we 
keep  up  with  what  is  going  on?  how  do  we  or  should  we  define  data?  how  do  we 
'tag*  data  to  indicate  quality,  meaning,  source,  etc.?  Other  recommendations: 
develop  a  data  source  catalog  that  identifies  “subject  matter  experts”;  develop  a 
standard  taxonomy  for  categorization  of  data;  develop  standard  nomenclature  for 
forces  and  equipment;  respond  to  increased  need  for  accurate  and  accessible 
unclassified  data;  support  a  M&S  bulletin  board  for  information  sharing; 
prioritize  standardization  efforts  using  importance/priority  of  individual  models 
and  simulations  as  a  guide. 

DIS  Data  Standards:  The  vision  is  of  synthetic  theaters  of  operations  shared  and 
simultaneously  operated  on  by  the  Army,  sister  Services,  and  the  defense 
community.  The  M&S  standards  foundation  consists  of:  data  element  standards, 
communication  standards,  standard  services  (e.g.,  data  centers),  physical  and 
algorithm  standards,  all  form  basis  for  different  M&S  which  are  then  linked  to 
form  DIS.  DIS  data  standards  will  allow  for  more  efficiency  and  stronger  V&V 

but  there  are  concerns  with  standards  having  a  life  cycle - standards  may  be 

based  on  past  practices,  use  may  institutionalize  out-dated  processes  and  may 
stifle  creativity  that  would  lead  to  improved  results.  In  spite  of  this,  standards  are 
the  foundation  for  common  capabilities  and  interoperability  in  DIS.  A  library  of 
standard  items  such  as  terrain,  nomenclatures,  icons,  approved  data, 
algorithms,  and  subroutines  are  critical  to  all  phases  of  warfare,  W&A, 
computer  generated  forces,  accurate  terrain  and  environmental  effects,  etc. 

Overview  of  data  standards  includes  efforts  in  areas  of:  (1)  dictionary/directory 
(AR  25-9,  DoDD  8320,  DDRS);  (2)  interoperability  standards  (IEEE  1278  PDU 
standards,  NATO  STANAG  4482);  (3)  common  nomenclature  (long  names,  short 
names,  US,  DLA,  TRAC/AMSAA/STRICOM);  (4)  expanded  DBMS  for  data 
providers  (atmospheric  aerosols  and  optics  at  Battlefield  Environmental 
Directorate  (BED),  global  electro-optical  environmental  matrix,  weather  library  at 
BED,  AMSAA);  (5)  center  data  systems  (OASIS,  J-MASS,  UTSS,  Extended  Air 
Defense  Test  Bed,  MIIDS,  CFDB/MSDS,  TADS);  (6)  information  sharing 
(MOSAIC  Army,  CCTT  date  library,  TWSTIAC,  DMSO);  and  (7)  education  (DIS, 
MORS,  AUSA,  I/DB). 

Mr.  George  Hurlburt:  Update  from  TECNET  Information  System  for  the  Test  and 
Evaluation  Community 

TECNET  has  had  a  ten  year  evolution.  The  key  1993  research  initiatives  are: 
database  evolution,  query/search  capability,  and  attention  to  a  multi-level  secure 
system.  George  went  through  the  evolution  of  TECNET  from  1983-1993  ending 
with  the  current  configuration  of  an  unclassified  TECNET  on  a  Sun  670  serving 
users  over  the  DDN/INTERNET  and  direct  dial-in,  and  a  secret  system  high 
TECNET  on  a  Sun  SPARC- 10  system  connected  through  DSNET  and  also 
servicing  STU  III  dial-in  users.  He  went  over  TECNET  management  showing  the 
makeup  of  the  TECNET  steering  committee.  The  1993  nearterm  developments 
include  cursor  driven  database  access,  combined  Test  and  Evaluation  resource 
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databases,  improved  repository  and  enhanced  facsimile.  Work  in  progress 
includes  hypersearch,  gopherAVAISAVorld-Wide-Web  and  windows  interface. 
Longer  term  developments  include  groupware  and  PC  based  mail  interface. 

The  TECNET  databases  that  have  data  elements  standardized  into  a  common  data 
dictionary  controlled  by  the  Range  Commanders*  Council  are:  ARRIIPS, 
TESTFACS,  T&E  Assets,  Range  Schedules,  OTECC,  LRPS,  and  MSTIRC. 
TECNET  is  developing  an  integrated  database  called  the  Joint  Test  Asset  Database 
(JTAD)  through  rapid  prototyping.  This  will  be  based  on  data  elements  from 
ATRIS,  TESTFACS,  and  Test  and  Evaluation  Assets  databases.  During  1992  -1993 
they  were  developing  an  IDEF1X  data  model  for  data  elements  from  the  common 
data  dictionary.  They  were  also  using  IDEFO  during  1993  to  develop  a  process 
model  of  how  the  JTAD  group  of  data  managers  and  users  will  function  utilizing 
JTAD  data.  They  will  then  do  a  functional  mockup  based  on  the  IDEFO  and 
IDEF1X  models  to  arrive  at  a  technical  specification  for  the  JTAD  by  1994  and  use 
that  to  arrive  at  a  full  scale  networked  relational  database  JTAD  by  1995. 

George  showed  the  Test  Resource  relationships  of  DMSO  M&S  to  environmental 
impact  data,  reliance  data,  and  threats  and  threat  simulations  and  those 
relationships  to  the  Test  Resource  Description  which  also  gets  data  from  Resource 
Utilization,  Financial  Tracking  and  Execution,  and  Resource  Investment  and 
Execution  databases.  He  also  showed  the  planned  TECNET  secure  information 
base  that  will  consist  of  EVADE  (ECM  database),  TIDES  (threat  and  threat 
simulations),  and  a  Common  TECNET  Interface  containing  a  hierarchical 
keyword  search  for  access  to  the  various  collections.  TIDES  will  contain  threat 
data  and  models  and  simulations  from  EWIR,  NERF,  NID,  Constant  Webb, 
TEARS  and  INNET,  and  TECNET  wants  to  add  data  from  AJTSH,  STARS,  EPL 
and  the  DLA  Handbook.  It  will  reside  under  Oracle  on  a  Sim  SPARC  10. 

Currently,  TECNET  I-CASE  tools  consist  of  IDEFO  and  IDEF1X,  and  relational 
DBMSs  (e.g.,  Oracle)  accessed  through  SQL  containing  data  or  pointing  to  data  in 
JTAD,  TIDES,  TEXIS,  etc.  They  are  thinking  of  using  an  Object-Oriented  DBMS 
to  manage  complex  data  including  M&S,  visuals,  and  raw  data.  Also  TECNET 
uses  the  internet  (gopher,  WAIS,  WWW)  for  handling/accessing  textual  data 
such  as  reports  and  abstracts.  In  the  future  they  are  anticipating  a  subject 
matter  knowledge  base  supported  by  “drones”  who  would  search  tightly  coupled 
relational  databases,  complex  data  and  textual  data. 

The  TECNET  vision  for  MLS  is  to  systematically  migrate  existing  TECNET 
resources  to  create  a  standards  compliant,  multi-level  secure  communications 
and  processing  capability  which  links  DoD  test  and  evaluation  entities  to  a  shared 
but  controlled  user  community  information  resource.  They  are  working  with 
NSA  to  accomplish  this.  They  will  be  performing  TECNET  secure  experiments 
with  a  1996  objective  of  supporting  email,  file  transfer,  news,  bulletin  board  and 
databases  over  multi-level  systems  through  DSNET. 

Included  in  the  appendix  is  a  short  paper  titled  “TECNET:  Evolution,  Capability 
and  Research  and  Development  Initiatives”  and  a  copy  of  the  TECNET  newsletter 
“TecNet  Inform”  that  describes  the  new  TECNET  menu  system. 
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3.5  DATA  ADMIN,  STANDARDIZATION,  AND  MODELING  ACTIVITIES 
Mr.  Phil  Cykana:  Update  on  DoD  Strategic  Data  Model 

The  DoD  strategic  data  model  represents  the  view  of  senior  officials  within  the 
DoD  about  what  is  important  to  the  DoD.  Its  purpose  is  to  provide  a  standard 
framework,  single  data  model,  single  starting  point,  single  data  architecture,  for 
identifying  improvement  opportunities;  anticipating  impact  of  management, 
process,  and  technology;  and  to  provide  initial  set  of  prime  words  to  use  in  data 
standardization.  It  was  released  for  comment  22  March  1993.  As  of  September 
1993,  there  were  many  responses  (157)  mainly  to  add  entities,  change 
relationships  and  change  definitions.  They  held  working  sessions  with  C2,  DMA, 
Acquisition,  and  CALS.  An  outcome  was  to  develop  the  C2  core  model  from  the 
battlefield  generic  hub  model  developed  for  NATO  and  integrate  it  with  the  DoD 
strategic  data  model.  The  DoD  strategic  data  model  is  relatively  stable  and  is  a 
mechanism  supporting  Enterprise,  mission  and  functional  area  integration.  The 
DoD  Data  Model  will  be  a  collection  of  integrated  functional  area  and  component 
data  models  developed  in  accord  with  the  DoD  8320.1  series. 

At  their  integration/reconciliation  sessions  they  made  observations  about  the 
differences  in  “information  about”  vs  “content  of ”  and  the  differences  in  strategic 
data  model  vs  functional  area  data  model  vs  model  for  data  element 
standardization.  Cykana  showed  a  picture  of  the  original  model  before  changes 
and  then  the  proposed  update  which  included  changing  “land”  to  “real  estate”  and 
adding  “action”  from  the  C2  core  model.  The  model  will  be  extended  to  include 
enumerated  domains.  He  showed  several  examples  of  using  the  DoD  Strategic 
Data  Model  to  show  a  functional  area  view.  In  discussing  the  functional  view  of  a 
document  he  discussed  distinguishing  document  content  from  the  information 
about  a  document  and  information  about  the  structured  content  of  a  document. 

Cykana  said  that  when  we  see  Duane  Hufford’s  models,  they  will  be  at  the  entity 
level  and  not  the  instance  level.  He  is  interested  in  recommendations  and 
comments  about  entities  vs  instance  data,  and  meta  data  vs  data.  This  addresses 
the  concept  that  one  person’s  entities  may  be  another  person’s  instances.  For 
example  at  high  resolution,  an  entity  may  be  a  specific  type  of  tank  (e.g.,  M1A1) 
with  instances  being  individual  tanks  while  at  lower  resolution  the  entity  may  be 
a  generic  tank  and  the  instances  specific  types  of  tanks. 

Question:  as  to  how  the  I/DB  members  can  get  hold  of  the  latest  DoD  Strategic 
Data  Model  documents.  Answer:  through  DTIC,  phone  1-800-225-3842.  Ask  for 
the  DoD  Enterprise  Model  (which  is  updated  every  six  months). 

Mr.  Jeff  Wolfe:  Defense  Information  Repository  System  (DIRS) 

Key  concepts  for  the  DIRS  project  is  (1)  single  logical  repository,  (2)  common  meta 
model  (core  data  model  for  Information  Management(IM)  and  standard  data 
elements  for  IM  community);  (3)  information  assets  are  related,  managed  and 
controlled;  and  (4)  addresses  migration  strategy.  Purpose  of  the  DIRS  project  is  to 
develop  the  requirements  for  a  DoD  information  repository  to  serve  four  major 
.activities:  Functional  Process  Improvement  (FPI),  Data  Administration  (DA), 
Software  Reuse  (SR),  and  Software  Engineering  (SE)  all  of  which  require  policies, 
procedures,  repository,  and  standards  and  need  program  interoperability  and 
data  sharing  as  well  as  support  for  process  improvement. 
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Many  organizations  are  participating  in  the  DIRS  Project  including  the  four  CIM 
activities,  DISA,  DoD  Components  and  NIST  and  there  are  many  areas  of 
expertise  that  have  contributed  including  M&S  with  its  complex  data 
requirement.  They  did  a  number  of  as-is  studies  including  the  Interim  IDEF 
repository,  DDRS,  Automated  Resource  Management  System,  DSRS,  and  others 
and  even  reverse  engineered  existing  repositories  to  get  data  items.  The  DIRS 
requirements  analysis  consists  of  an  as-is  analysis  producing  process  and  data 
models,  a  to-be  analysis  to  define  the  repository  meta  model  and  a  requirements 
definition  to  get  a  repository  functional  description 

The  to-be  analysis  has  produced  a  fully  attributed  meta  model  that  supports  a  data 
administration  view  of  logical,  internal  and  external  data  models.  Wolfe  showed 
us  a  viewgraph  of  the  to-be  data  model  containing  example  categories  of  the 
information  assets  (e.g.,  functional-activity-model,  conceptual-data-model,  data- 
entity)  and  a  model  of  the  management  information  assets  (e.g.,  security- 
classification,  authoritative-document,  functional-area). 

Wolfe  said  that  naming  should  fall  out  of  the  model  without  needing  to  specify  any 
of  the  conventions  put  forth  by  CIM  (note:  I/DB  may  want  to  explore  this  further). 
He  estimates  that  there  are  close  to  200  entities  they  will  want  to  control  and 
manage,  of  which  about  22-23  are  information  assets.  For  each  asset  they  will 
want  to  maintain  a  history,  life  cycle,  facets  (taxonomy,  search  key),  etc.  They 
will  be  entering  their  data  model  into  the  CIM  data  approval  process.  In  the 
technical  analysis  phase,  they  did  a  COTS  study  of  repository  tools  (I/DB  would 
like  to  get  a  copy  of  this  report).  They  also  did  a  technical  assessment  of 
implementation  alternatives  for  the  repository  such  as  distributed  vs  centralized 
vs  client-server  and  costed  these  out. 

Question  as  to  when  the  repository  will  be  available.  They  are  in  the  requirements 
phase,  are  doing  a  functional  description  and  meta  model  and  are  comparing 
performance  requirements  to  FIPS  156  for  flexibility,  extensibility  and  vendor 
independence.  They  want  NIST  to  review  their  requirements  analysis  in  light  of 
the  standards  community. 

Question  about  others  reviewing  their  metamodel:  they  will  try  to  get  a  copy  to 
Chien  Huo  and  he  will  make  it  available  to  the  I/DB  community.  One  can  also  get 
training  material  from  Stan  Plummer. 

Mr.  Stan  Plummer:  JIEO  Update  on  C2  Data  Modeling 
The  C2  Functional  Data  Administrator’s  mission  is  to  achieve  a  fully 
interoperable  C2  environment  through  an  effective  data  standards  program, 
develop  data  standards  and  data  models  for  C2  projects,  and  to  develop  C2  FDAd 
policies  and  procedures,  and  planning,  analysis,  modeling,  configuration 
management,  storage,  retrieval,  validation  and  documentation  of  data.  Under 
MCEB  guidance:  In  July  1993  they  published  the  C2  core  data  model  and 
developed  C2  Interim  Data  Elements;  and  in  January  1994  established  the  Global 
Command  and  Control  System  (GCCS)  as  the  conceptual  migration  system  for 
theater  level  C2;  and  established  data  standards  and  common  operating 
environment  (COE)  as  key  to  integration.  In  support  of  GCCS  they  have  produced 
IDEF1X  data  models  for  C2  Core,  fire  support,  joint  air  operations,  and  SOCOM; 
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and  JUDI  data  elements  as  common  “interlingua”  for  Component  systems. 
Products  available  to  the  C2  community  are:  C2  core  data  model  and  extensions 
and  C2  portion  of  Do D  data  element  standards  “starter  set”.  This  consists  of  1300 
interim  data  elements  that  haven’t  been  approved:  200  belong  to  JUDI,  and  the 
rest  are  previous  data  elements  from  JOPES  and  the  Army.  No  later  than  March 
1,  they  will  submit  C2  core  data  model  entities/prime  words  and  developmental 
and  candidate  DEs  to  result  in  standard  data  elements  (SDEs).  By  Feb.  16  had 
submitted  109  entities  and  had  8  approved  prime  words,  and  submitted  297  data 
elements  and  had  5  approved  and  8  as  candidates.  It  is  taking  about  3  weeks  from 
submitting  the  proposal  to  CIM  until  CIM  enters  these  as  candidate  DEs  and  then 
a  month  longer  to  be  approved  as  SDEs.  There  is  no  proposal  package  yet  for  the 
1300  starter  set.  They  are  improving  the  way  they  prepare  proposal  packages  for 
submission.  The  DISA  guidance  has  been  to  submit  the  proposal  package  and 
then  proceed  with  development  keeping  track  of  changes  to  the  DEs  as  they  are 
accepted/rejected  by  DISA.  The  proposal  package  for  the  fire  support  model  will 
be  submitted  by  April  1994,  the  SOCOM  package  by  3rd  quarter  FY94,  and  fully 
attributed  model  for  joint  air  operations  in  FY94.  In  Dec  93  they  loaded  the  joint 
air  operations  model  into  the  Interim  IDEF  model  repository,  and  in  Jan  94 
submitted  the  C2  core  data  model  to  the  repository. 

Peter  Valentine:  Report  on  IDEF  Users’  Group  Meetings  and  Issues 
The  Last  IDEFlX  meeting  was  held  in  Salt  Lake  City  November  1993.  The  IDEF 
FIPS  were  published  December  21,  1993:  FIPS  PUB  183  -  IDEF0  Process 
Modeling,  and  FIPS  PUB  184  -  IDEFlX  Information  Modeling.  The  draft  IDL  for 
IDEF0  was  completed  and  the  meta-model  sub-group  was  closed. 

A  new  IEEE  IDEFlX  Working  Group  1320.2  was  formed  mainly  with  industry 
members  committed  to  updating  products.  Some  issues  to  be  addressed  include: 
meta-model;  relationship  of  IDEFlX  to  Zachman  Framework  and  other 
frameworks;  extensions  to  IDEFlX  language:  object  identity  and  object 
orientation,  “fixes”  to  language  peculiarities,  expanding  domains  to  abstract  data 
typing,  DBMS  independent  language  for  expressing  complex  rules  and  methods; 
and  use  of  SML  as  Interchange  Language.  SML  is  being  used  by  many  vendor 
tools.  Bruce  Rosen  suggested  use  of  ASN.  1  (abstract  syntax  notation.  1)  but 
vendors  felt  they  had  an  investment  in  SML  and  didn’t  want  to  change.  The  next 
IEEE  IDEFlX  WG  1320.2  will  be  held  in  Seattle  March  3—5  and  Pete  will  be 
attending.  The  items  to  be  discussed  include:  change  management, 
formalization,  extensions,  meta-model,  and  user  man  usd.  They  will  also  be 
looking  at  a  certification  test  for  IDEFlX  tools,  deadline  is  September  1994. 

Lud  Haddad:  CCTT  Data  Standardization  and  Reuse 
They  have  taken  the  four  DISA/CIM  initiatives  (Functional  Process 
Improvement,  Data  Administration,  Software  Reuse,  and  Software  Engineering) 
and  tried  to  implement  them  at  the  Army  Component  level.  Three  of  the  CCTT 
systems  use  data  from  other  sources  that  had  different  nomenclatures  so  they 
have  used  TRAC  (Howard  Hacker’s)  standard  nomenclature.  They  have 
narrowed  the  scope  of  the  data  model  to  the  M1A1  tank  and  will  just  provide  the 
developers’  data  requirements  using  the  TRAC  data  model.  When  they  develop 
data  models  and  standards,  they  first  search  for  occurrence  in  an  authoritative 
source  (e.g,  DDRS,  ADDS). 
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Luci  commented  on  their  previous  approach  to  data  standardization  which  was 
based  on  Army  Regulation  25-9.  It  consisted  of  researching  data,  modeling  and 
developing  data  elements,  submitting  data  elements  to  the  PM-CATT  data 
administrator,  submitting  PM-CATT  approved  data  elements  via  batch  to  the 
ADD,  and  tracking  data  elements  through  final  approval.  The  problem  is  the 
directive  to  use  DoDD  8320.1-M-l  rather  than  AR  25-9.  There  are  differences 
between  them  in  data  element  naming  conventions  and  in  the  metadata  used  to 
describe  the  data  elements.  In  July  1993,  Erwin  Atzinger’s  memo  to  use  ADD 
standards  was  modified  to  say  that  the  Army  was  migrating  to  DoDD  8320.1-M-l, 
and  on  4  Jan  94,  DoDD  5000.59,  DoD  M&S  Management  required  that  data  and 
data  administration  for  DoD  M&S  applications  conform  to  policies  and  procedures 
specified  in  DoDD  8320.1.  CCTT  intends  to  follow  DoDD  8320.1. 

In  the  research  world  they  have  found  an  effort  called  the  domain  analysis  study 
of  software  systems  and  have  been  talking  to  UNISYS  about  their  STARS  initiative 
for  reuse  in  a  domain  specific  area.  They  would  use  IDEF0  to  model  the  software 
process.  They  are  researching  this  approach  now  and  are  looking  at  domain 
analysis  tools.  One  reuse  problem  with  M&S  data  is  that  often  when  you  acquire 
outside  source  data  for  M&S,  there  is  a  need  to  convert  it  in  some  way  using 
algorithms.  These  algorithms  really  need  to  be  stored  and  reused  with  the  data. 

Ms.  Ms  Kameny:  Report  on  TADS  Weapon  Performance  Data  Modeling 
Objectives  of  the  pilot  study:  (1)  to  produce  a  data  model  of  five  weapon 
performance  areas:  target  acquisition,  direct  fire,  artillery,  mines,  and  weather; 

(2)  produce  a  naming  scheme  for  entities  and  data  elements  to  be  integrable  with 
the  CIM  Enterprise  and  C2  Core  data  models;  (3)  develop  8320.1-M-l  descriptions 
of  the  data  elements;  and  (4)  report  to  I/DB  task  group  on  lessons  learned.  Only 
tasks  1  and  4  were  carried  out  by  the  pilot  study;  TRAC  did  (2)  and  (3)  itself  except 
that  the  data  element  standards  were  submitted  to  the  AMSMO  for  submission 
into  the  ADDs  process,  and  then  to  be  submitted  to  the  DoD  process. 

The  briefing  included  reasons  for  selection  of  TADS  for  the  pilot  study,  approach 
to  the  study,  equipment  used,  procedures,  some  statistics  for  the  five  areas  (i.e.,  13 
independent  entities,  29  associative  entities  and  6  categories)  and  lessons  learned. 
TADS  related  lessons  learned  included:  benefited  from  TADS  experience  with 
RDBMS;  started  anew  with  naming;  needed  experts  at  all  sessions;  estimated 
data  modeling  took  50%  of  total  effort;  TADS  not  impressed  with  use  of  IDEF1X  to 
help  them  better  understand  their  data  or  affect  future  data  structures;  suggest 
being  careful  to  distinguish  between  “data  model”  and  “model”  during  process; 
and  foresee  big  PR  problem  in  selling  data  modeling. 

DoD  related  lessons  learned:  need  for  standard  data  models  in  infrastructure  areas; 
problems  using  associative  entities  for  modeling  complexly  derived  data;  lack  of  DoD 
taxonomy  of  meaningful  entities/prime  words;  issues  with  naming  of  data  elements 
(names  can  become  very  long  and  not  meaningful  and  entity  names  are  overloaded 
by  using  them  both  as  unique  identifiers  and  for  providing  taxonomy);  overloading 
use  of  IDEF1X  (logical  modeling/  user  understandability  and  also  for  generating 
normalized  models);  overloading  associative  entities;  need  for  DoD  guideline  for 
naming  of  associative  entities  using  names  of  participating  entities;  and  need  better 
way  of  identifying  special  types  of  relationships  like  part-whole  and  recursion. 
Lessons  learned  with  relation  to  IDEF1X  and  ERwin/ERX  tool:  use  of  the  tool  made 
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time  in  sessions  more  effective  and  enforced  language  rules  but  the  tool  lacks  the 
ability  to  represent  cardinality  ranges  and  was  restrictive  in  not  allowing  the 
naming  of  foreign  keys  by  concatenating  the  originating  entity  name  to  help  explain 
key  migration.  The  group  suggested  projection  of  the  tool  to  a  large  screen  would  be 
better  than  using  the  tool  on  a  workstation  with  the  group  developing  the  data  model 
on  an  automated  white  board. 

Mr.  Mike  Rybacki  and  Mr.  Jim  Glymph:  Army  Modeling  and  Simulation 
Management  Office  Discussion  on  Data  Standards 

The  advantage  of  the  way  the  Army  maintains  standards  is  that  it  looks  across 
functional  areas.  The  Army  has  In^rma  m  Classes  (IC)  and  each  is  headed  by 
an  Information  Class  Proponent  (I*  An  Army  project/system  submits  data 
elements  for  standardization  to  its  lv,  °  which  is  responsible  for  building  its  ICP 
functional  data  model  and  submitting  it  to  the  Army  Information  Systems 
Command  which  integrates  all  Army  functional  models  into  the  Army  data 
model.  The  Army  data  model  will  be  integrated  into  the  DoD  Enterprise  Data 
model  when  the  Army  data  modelers  transition  to  JIEO/C1M  in  the  near  future. 
There  are  data  standardization  concerns  with  three  incompatible  standards: 

Army  AR  25-9,  DoD  8320.1-M-l,  and  IEEE  1278  for  DIS  PDUs. 

The  key  technical  challenges  are:  data  model  abstraction  and  partitioning, 
reconciliation  of  divergent  data  sharing  strategies,  and  complex,  complicated, 
derived  data.  In  summary:  data  standardization  is  essential  for  information 
system  interoperability;  data  standardization  can  save  money  through  reuse  of 
data  models  and  data  elements;  the  Army  Data  Model  could  serve  as  a  core  for  a 
detailed  enterprise  data  model  with  DoD-wide  applicability;  and  we  must  meet 
several  technical  challenges  to  keep  the  program  viable  in  the  future. 

Jim  Glymph:  differences  between  DoD  and  Army  standards  are  small,  class 
words  are  different,  there  is  a  difference  in  qualifiers  in  naming  (e.g..  Army 
would  include  weight  units),  and  the  differences  in  metadata  elements  seems 
greater  than  it  is  since  some  of  the  Army  metadata  elements  are  not  used  based 
on  current  priorities,  etc.  There  are  already  1500  entries  in  the  Army  Data 
Dictionary  as  compared  to  two  or  three  in  the  DDRS.  The  ADD  team  has  a  backlog 
of  fifty  Army  functional  area  data  models  waiting  to  be  integrated  into  the  Army 
data  model.  The  Army  has  four  years  experience  in  doing  data  modeling.  Soon 
ISC  will  transition  its  data  modeling  staff  of  38  to  DISA  to  work  on  the  DoD  data 
model. 

a6  PROGRESS  ON  DIRECTORIES 

Mr.  Roy  Scrudder:  Data  Model  for  M&S  Directory 

This  effort  started  as  an  update  of  SSDC’s  Analytical  Tool  Box  with  DMSO  support 
to  develop  a  DoD  standard  data  model  for  an  M&S  directory.  The  Joint  Data  Base 
Elements  (JDBE)  Project  provided  training,  review  and  consulting  and  IDA  will 
provide  prototype  implementation.  The  M&S  directory  information  sources 
included:  the  Army  MOSAIC  system,  J8  Catalog  of  Wargaming  and  Military 
Simulation  Models,  Navy  SMART  Program,  SSDC  Analytical  Tool  Box,  and  CNA 
Survey  for  DMSO  1/DB.  Activities  included:  a  draft  data  model  developed  by 
COLSA;  model  review  by  DMSO,  SSDC,  AMSMO,  DIA/MISIC,  SMART  and 
JDBE;  and  model  update  by  JDBE  to  reflect  review  comments.  The  M&S 
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taxonomy  was  to  be  supported  by  SSDC  and  DMSO  but  was  not,  and  so  it  includes 
only  the  rudimentary  facets  of:  purpose,  application  area,  level  modeled,  domain, 
scope  of  conflict.  The  follow-on  objectives  are  to:  integrate  the  M&S  Directory  and 
Data  Base  Directory  Data  Models;  complete  the  M&S  Directory  taxonomy  and 
domain  information;  add  D ISA/C IM-compliant  naming;  submit  integrated  data 
model  as  an  extension  to  the  DoD  data  model;  submit  candidate  standard  data 
elements;  and  develop  prototype  M&S  Directory  and  Data  Base  Directory. 

Roy  went  over  the  entity-relationship  model  and  several  people  expressed  interest 
in  using  the  model  and  attending  the  next  session  to  review  the  model  (hopefully 
the  final  time  around). 

Question:  Is  this  an  adequate  data  model  to  describe  object-oriented  models  that 
are  federated?  Answer:  You  can  state  in  the  M&S  Directory  that  the  M&S  input  is 
objects. 

Question:  Do  we  need  a  history  of  the  derivation  of  the  model?  Answer:  Change 
in  name  should  be  captured  as  separate  model  entry 

Question:  Respect  to  taxonomy?  Answer:  Decide  facets  and  then  levels 

Dr.  John  Griffiths:  Intelligence  Community  M&S  Catalog 
I.C.  M&S  Catalog  terms  of  reference:  gather  data  on  M&S  accomplishments, 
activities,  and  centers  of  interest  in  the  IC;  store  and  access  information  to  share 
technology,  methodology  and  data  regarding  IC  M&S;  and  make  M&S  available  to 
Government  Agencies  and  sponsored  support,  consistent  with  security 
constraints.  Existing  M&S  catalogs  include  the  following  that  are  on-line  at 
DMSO  via  Internet:  JCS  J-8  Catalog,  Army  M&S  Catalog,  Navy  M&S  Catalog, 
Rome  Labs  M&S  Catalog;  and  DMSO  M&S  system.  There  will  be  two  components 
to  the  IC  M&S  Catalog:  unclassified  and  classified.  The  unclassified  component: 
will  parallel  J-8  and  Service  Catalogs;  will  exist  at  DMSO  and  on  classified 
component  machine;  will  be  available  via  internet  to  qualified  users  via  DMSO; 
will  have  excluded  entries  of  sensitive  but  unclassified  programs  and  data 
(excluded  by  Intel  agencies);  and  in  such  cases  the  unclassified  catalog  entry  will 
contain  only  a  POC.  The  classified  component  will:  exist  on  a  dedicated  stand¬ 
alone  PC  in  CIA  spaces;  make  data  available  to  qualified  cleared  users  via 
hardcopy  and  softcopy;  will  rely  on  agencies  to  determine  qualification  and 
clearance  level  of  individuals  to  have  access  to  listed  programs  and  data;  furnish 
POCs  only  for  specially  compartmented  M&S  programs;  and  have  on  the 
classified  database  machine  unclassified  DMSO  catalogs  for  use  of  personnel  and 
agencies  without  internet  access. 

Status:  386/33  machine,  170  Mb  removable  storage,  Oracle,  dBase  IV,  Alpha  Four, 
M&S  access.  The  DMSO  M&S  catalogs  will  reside  on  the  machine  for  IC 
members  without  internet  access.  The  IC  data  call  will  be  issued  as  soon  as  the 
new  M&S  catalog  standard  can  be  translated  into  a  data  call.  The  classified 
component  of  the  catalog  will  contain  additional  fields. 

Dr.  Mike  Frame:  Discussion  of  Next  Steps  for  Database  Directory  and  Model  and 
Simulation  Directory  Implementation 
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Status:  logical  design  for  Database  Directory  exists,  a  preliminary  logical  design 
for  M&S  Directory  exists  with  one  more  review  to  be  scheduled,  and  a  plan  has 
been  developed  for  creating  and  populating  the  database  and  providing  user 
access.  There  are  six  implementation  steps:  (1)  integrate  data  models  of  M&S  and 
Database  Directories,  (2)  do  initial  physical  database  design  and  implementation, 

(3)  do  final  physical  database  design  and  implementation,  (4)  develop  support  for 
populating  database  (5)  develop  support  for  database  query  and  browsing,  and  (6) 
install  production  version. 

Implementation  of  the  initial  physical  databases  is  expected  to  be  completed  by 
March  1994  on  IDA  prototype  system.  Information  will  be  collected  about  major 
sources  of  data  and  the  creation  of  the  final  physical  database  designs  using 
Oracle  will  be  completed  by  June  1994  on  the  IDA  prototype  system.  There  is  a 
plan  for  developing  support  for  populating  the  database  through  bulk-load,  low 
volume  load,  user  interface  for  data  entry,  and  to  design  for  database 
maintenance.  There  is  a  plan  to  develop  support  for  database  query  and  browsing 
by  determining  a  standard  set  of  queries  and  browsing  paths,  implementing 
scripts,  and  designing  and  implementing  a  user  interface  that  uses  standard 
queries  and  browsing  paths  as  well  as  a  help  facility  for  unusual  queries.  The 
systems  will  be  tested  and  finally  installed  at  the  DTIC  production  site. 
Requirements  for  data  population  and  browsing  tasks  will  be  defined  in  early 
siimmer  1994  with  goal  of  having  production  system  running  in  early  1995. 

Suggestions: 

(1)  Look  at  X.500  directory  standards 

(2)  Look  to  Army  AMSMO  for  experience  with  MOSAIC 

(3)  Write  baseline  concept  of  operations  on  how  the  directory  systems  should  work 

(4)  Look  to  Services  to  coordinate  data  entry  and  provide  review  rather  than  DMSO 
doing  so 

(5)  Allow  people  to  put  in  information  about  future  databases 

(6)  Do  a  tradeoff  of  timely  data  in  Directory  vs  time  it  takes  to  review  and  hold  up 
availability  of  timely  data 

(7)  Look  at  data  elements  such  as:  data  submitted  by  and  date,  reviewed  by  and 
date,  approved  by  and  date 

(8)  Look  at  ARMS  querying  interfaces  (Navy  project) 

(9)  Look  at  use  of  natural  language  interface 

(10)  Look  at  CONOPS  for  Directory  client-server  model 

3.7  PROJECT  REPORTS 
Capt  Bill  Cashman:  J-MASS 

J-MASS  addresses  the  problem  that  current  M&S  were  designed  for  specific, 
narrowly-defined  purposes  without  built  in  interoperability  and  reuse.  Lack  of  a 
common  M&S  system  results  in  inconsistent/non  credible  results;  too  much  effort 
to  upgrade  or  modify  existing  models;  new  models  always  need  to  start  afresh;  the 
M&S  infrastructure  is  continually  reinvented  and  W&A  always  has  to  start  from 
"square  one”.  J-MASS  is  designed  to  provide  standards  (to  promote  reusable, 
modifiable,  maintainable,  interoperable,  and  more  easily  validated  M&S),  tools 
that  make  the  standards  transparent  to  users,  and  a  common  system  for 
developing,  using  and  reusing  M&S.  The  toolset  lets  users  create  models,  pull  in 
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existing  models  and  modify  them,  set  up  simulation  runs,  execute  simulations, 
and  analyze  simulation  results.  J-MASS  provides  toolset,  experts  provide  models. 
Design  goals:  both  realtime  and  non  realtime  (currently  non  realtime);  support 
for  varying  levels  of  model  fidelity  (not  well  thought  out  now);  scalable;  portable; 
distributed  (now  single  processor);  ability  to  play  in  DIS  exercises  (not  yet);  license 
free;  ability  to  customize;  ability  to  connect  to  legacy  models;  support  for  Ada  and 
C++  models;  and  visual  programming  to  generate/modify  models.  J-MASS 
provides  a  common  architecture  the  experts  can  use  to  build  models  for  the  DoD 
community.  J-MASS  today  (release  2.0):  provides  first  real  functionality  to  build 
models,  run  simulations  and  analyze  results,  built  on  Sim  workstation  and  soon 
Silicon  Graphics,  has  graphical  model  development  tool,  simple  plotting  and 
animation  tools,  initial  modeling  hbrary,  and  demonstration  of  J-MASS/DIS 
interface  using  old  1.0  PDUs.  Release  3.0  in  Dec  94  will  have:  initial  realtime 
simulation  capability,  ability  to  split  simulations  across  multiple  processors, 
abihty  to  use  both  Ada  and  C++  models,  backward  compatibility  with  release  2.0, 
and  a  “how  to”  manual. 

In  response  to  audience:  there  are  currently  no  J-MASS  guidelines  for  the  person 
building  a  model  but  they  expect  these  to  evolve  in  time.  Part  of  J-MASS 
specifications  includes  interface  specs.  They  expect  domain  specific  standards  to 
be  developing  soon.  The  J-MASS  toolset  is  just  leaving  the  prototype  phase. 

Question:  Change  to  COTS?  Answer:  There  will  be  an  architecture  concepts  run¬ 
off  addressing  software  backplane  standards  on  how  to  plug  in  COTS 

Question:  Ability  of  realtime  for  release  3.0?  Answer:  will  not  be  able  to  do  cockpit 
simulation  with  release  3.0 

Mr.  Mike  Sarkovitz:  Update  on  Universal  Hireat  System  for  Simulators 
UTS  is  the  joint  service  repository  for  DLA  approved  threat  data  and  validated 
real-time  simulation  software  used  as  standardized  input  to  DoD  training 
simulation  programs.  UTSS  participants:  Navy  is  lead  service  with  support  of 
other  services  and  DIA.  Current  status  is:  a  requirements  analysis  has  been 
completed  and  is  being  analyzed  to  determine  user  needs  in  the  DoD  aviation 
communities.  It  was  based  on  information  collected  from  70  sites.  A  technology 
evaluation  has  been  completed  and  is  being  reviewed  by  UTSS  working  groups 
and  the  EXCOM.  The  User  Needs  Analysis  has  been  drafted  and  is  in  review  by 
UTSS  working  groups.  The  current  findings  are  that  the  technical  evaluation 
and  user  needs  analysis  have  produced  87  aircrew  requirements.  The  original 
collection  was  of  Navy  Air  but  during  FY94  they  will  look  at  Army  ground  and 
Navy  undersea  and  surface  forces.  Future  of  how  UTSS  will  work:  training 
simulator  sites,  contractors,  and  designers  and  developers  will  request  UTSS 
standards  for  new  simulators,  initial  UTSS  software,  new  and  updated  databases, 
and  catalog  of  M&S  with  W&A  information.  The  current  plans  call  for  building 
the  system  with  government  resources  at  a  purple  site  though  it  is  not  certain  yet 
whether  it  will  be  a  central  repository  or  up  to  three  satellite  repositories.  The 
UTSS  man-machine  interface  can  be  used  to  help  the  requestor  draw  a  picture  of 
the  kind  of  simulator/simulation  he/she  is  interested  in  and  this  would  be  used  as 
a  filter.  DoD  instruction/directive  will  state  that  threat  database  and  realtime 
simulator  will  fit  into  a  training  device  and  any  threat  update  can  be  easily  made 
in  the  training  device  by  replacing  a  module.  The  concept  is  that  the  contractor 
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builds  the  trainer  leaving  room  and  interfaces  for  the  threat  database  and 
realtime  simulator  module.  W&A  of  the  simulator  is  done  after  the  threat  is 
placed  in  the  simulator.  UTSS  is  working  with  CATT  and  BFTT  to  determine 
their  threat  needs  and  is  DIS  compliant.  Networking  and  mission  rehearsal  is 
not  required  currently  across  Navy  and  Air  Force  platforms.  JDBE  personnel  will 
be  part  of  UTSS  WGs  and  will  be  helping  with  IDEF1X  data  modeling  and  IDEFO 
process  modeling. 

LCDR  John  Letaw.  Update  on  Naval  Warfare  Tactical  Data  Base 
The  NWTDB  is  a  management  process,  a  common  database  architecture  that  is 
more  than  a  metadata  repository,  and  a  path  to  common  sensor-to-shooter 
connectivity.  In  1986  NAVINTCOM  produced  a  prototype  Naval  Intelligence 
Database  (NID).  In  1990  NWTDB  was  formally  established  by  adding 
environmental,  cryptologic,  forces  and  facilities.  In  1992,  the  NWTDB 
Management  Plan  was  published.  In  1993  the  first  edition  of  the  NWTDB 
Standards  Manual  was  published,  and  in  1994  the  NWTDB  Implementation  Panel 
was  formed  to  consider  and  resolve  issues  relating  to  data  migration  of  existing 
systems.  NWTDB  process  is:  determine  information  requirements  and  user 
validation,  develop  data  standards  and  structures  definition  and  validation,  start 
reference  database  production,  implement  the  system,  do  operational  database 
management,  and  feedback  to  information  requirements.  The  database 
architecture  uses  a  common  interface  "language”  and  includes  standardized  data 
elements  (including  MTFs  and  TADILS),  normalized  logical  structure,  and 
designated  authoritative  sources.  This  will  evolve  to  an  open  systems  architecture 
with  a  Systems  Information  Directory  (SID)  of  standard  data  elements, 
standards,  and  structures  manuals.  Users  will  be  served  by  use  of  standard  user 
profiles,  data  produced  to  NWTDB  standards  and  structures,  and  distributed  in 
agreed  multimedia  formats.  Future  directions:  focus  on  high  quality,  timely  data 
fill,  add  tactical  system  data  structures  into  NWTDB,  revise  Standards  Manual 
every  6  months,  prepare  configuration  management  plan,  integrate  NWTDB 
standards  into  the  DoD  C2  data  model  and  envision  goal  of  evolving  existing  data 
elements  to  Joint  standards  by  1997. 

Questions:  Who  is  SPAWAR  POC?  What  are  the  functional  areas?  Questions: 
MTFs  and  TADILS:  Looking  at  issue  of  standardizing  these.  JIEO  has  worked  on 
loading  them  into  the  DDRS,  but  is  TADILS  worth  standardizing? 

They  are  receiving  DMSO  project  support  through  ARMS  and  NWTDB. 

Contact  John  Letaw  at  703-697-3033  for  standards  documents. 

Jack  Teller:  DoD  Project  on  Spatial  Data  Element  Standardization 
The  DMA  mission  is  to  provide  worldwide  coverage  data  about  the  real  world  that 
has  military  significance.  They  have  the  job  of  modeling  the  planet  earth 
restricted  to  surface,  below  surface,  ocean  bottom  and  some  coastal  areas.  CIM 
came  knocking  on  their  door  last  year  with  respect  to  developing  a  data  model  for 
MC&G  data.  They  started  with  the  international  standard  of  around  300  features. 
CIM  provided  training  and  funding  for  the  effort.  It  took  about  six  people  4  1/2 
months  (August  to  November  1993  with  one  week  training)  to  develop  a  fully 
attributed  data  model  for  MC&G  data  in  4th  normal  form.  They  have  identified  75 
potential  standard  data  elements  that  include  management  data  used  to  control, 
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maintain  and  provide  features.  An  initial  package  of  ten  elements  that  deal  with 
the  basic  ingredients  of  FEATURE  have  been  submitted  to  CIM  and  there  is  work 
in  progress  on  geometry  and  topoiogy  packages. 

In  doing  the  data  modeling  they  discovered  that  many  other  players  were 
modeling  spatial  aspects  of  MC&G  data  even  though  DMA  is  the  recognized  DoD 
authority  for  MC&G  data.  They  ran  into  conflicts  over  basic  concepts  and  the  use 
of  words.  For  example:  feature,  location,  point,  area,  volume,  attribute, 
coordinate — words  with  specific  meanings  in  the  MC&G  area,  were  already  being 
used  and  defined  differently  or  had  been  reserved  as  CLASS  words  in  the  DoDD 
8320.1  data  standardization  process. 

An  important  lesson  that  they  learned  was  that  DMA  can’t  achieve  data 
standardization  for  MC&G  data  alone.  Standardizing  commonly  used  data 
elements  requires  a  joint  DoD  approach.  It  is  not  enough  to  get  experts  in  their 
functional  area  together,  but  they  also  need  to  involve  the  users  of  the  data  from 
other  functional  areas  that  consider  themselves  “experts”  in  the  use  of  MC&G 
data  in  their  areas. 

Their  current  approach  is  to  assemble  a  team  of  players  from  DoD,  USGS, 
intelligence  agencies,  and  other  federal  agencies  with  guidance  or  leadership  and 
funding  from  DISA  and  participation  and  joint  orchestration  from  DMA.  The 
project  objective  will  be  to  integrate  all  the  different  existing  activity  and  data 
models  that  involve  use  of  MC&G  data  with  the  DoD  Enterprise  model.  The 
project  will  be  well  scoped  to  (1)  develop  a  fully  attributed  data  model;  (2)  produce  a 
submission  package  to  CIM  containing  at  least  10%  of  the  Feature  Attribute 
Coding  Catalog  objects  and  their  associated  data  elements,  and  (3)  a  schedule  for 
producing  the  rest  of  the  data  elements. 

The  benefits  of  this  approach  are  that:  duplication  of  effort  is  eliminated;  data 
elements  are  produced  that  everyone  can  use;  it  will  enhance  the  DoD  Enterprise 
Model  with  models  from  joint  team  efforts;  coordinating  the  development  of  data 
standards  will  more  rapidly  achieve  FDAd  approved  data  element  candidate 
status;  and  it  will  bring  DoD  and  other  federal  agencies  closer  together  in 
concurring  on  Spatial  Data  Standards.  The  disadvantages  are:  it  requires 
commitment  from  all  participants  and  they  must  be  from  the  right  functional 
areas,  be  experienced  people  and  be  empowered  to  speak  and  make  decisions  for 
their  organizations. 

Mr.  Stephen  Boyd:  Air  Force  Studies  and  Analysis  Power  Projection  Database 
Project 

AFSAA  products  are:  long  term  studies,  support  to  COEAs,  responses  to  Air  Staff 
questions  and  participation  in  the  Program  Acquisition  cycle.  They  do  analyses  of 
weapon  systems  and  deliver  the  results  in  different  formats.  Their  analyses  are 
supported  by  computer  models  ranging  from  engineering  level  models,  to 
functional  level  models,  to  engagement  level  models,  to  campaign  level  models. 
The  study  manager  is  responsible  for  all  aspects  of  the  data.  They  see  a  need  to  do 
something  about  their  data  because  they  find  it  is  difficult  to  create  consistent 
scenarios  for  models  with  different  levels  of  abstraction,  difficult  to  capture 
knowledge  of  the  data  process  from  study  managers,  there  is  an  increasing  need 
for  detail  in  abstract  models,  and  their  analysis  staff  is  shrinking.  The  solution  is 
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to  manage  the  data  by:  centralizing  the  database  collection,  use  data  management 
tools  and  study  management  tools  to  help  the  study  manager,  use  cartographic 
and  geographic  display  to  show  analysis  starting  conditions  and  results,  and 
develop  tools  to  capture  a  history  of  the  study  and  display  results.  They  are  using 
an  incremental  approach  that  includes  creating  data  management  standards 
and  combines  existing  data  management  functions  into  a  single  set  of  processes. 
They  are  also  avoiding  having  to  make  changes  to  models  in  order  to  implement 
the  data  management  processes.  Their  need  is  for  a  database,  a  tool  set  for 
database  development,  and  a  tool  set  for  analysts  that  supports  their  use  of  data 
and  models. 

They  need  GUIs  for  managing  the  data,  for  study  management  and  for 
cartographic  display.  They  have  a  visual  programming  environment  (VPE)  to 
make  it  easy  for  modelers  to  develop  applications  that  can  pull  out  the  data  needed 
by  a  model  and  convert  it  into  formats  appropriate  for  models.  (The  VPE  license  is 
$5,000  and  runtime  version  is  $1,000  and  they  will  furnish  AFSAA  code  to  those 
interested.)  They  have  developed  a  filter  script  language  in  formatted  ascii  that  is 
user  friendly  and  provides  access  to  SQL  queries.  They  are  also  providing  archival 
tools  for  data  and  analyses. 

There  are  overhead  costs  for  implementation  and  use  of  this  system.  Splitting  the 
data  management  functions  between  the  study  manager  and  the  data  manager 
may  cause  slower  reaction  time  in  setting  up  the  study.  Essentially,  there  is  a 
central  database  with  central  management,  and  each  study  manager  maintains 
his  copy  of  that  portion  of  the  database  that  is  necessary  for  his  study.  The  data 
manager  for  the  study  manager  can  change  the  data  to  meet  study  requirements, 
and  is  responsible  for  verifying  and  authenticating  the  data  for  the  study  at  hand. 

If  the  data  he  gets  from  the  central  database  is  flawed,  better  data  may  be  requested. 

The  briefing  ended  with  tasks  to  define  requirements  for  the  data  management, 
study  management  and  cartographic  GUIs,  establish  timelines  and  establish 
integration/model  tests. 

Mr.  Steve  Matsuura:  Joint  Data  Base  Elements  Project 

The  JDBE  effort  has  been  briefed  at  many  I/DB  meetings.  JDBE  is  (1)  developing 
candidate  standard  data  elements  and  data  models  for  M&S;  (2)  provides  the  M&S 
community  with  a  reverse-engineering  data  modeling  methodology;  (3)  provides  a 
methodology  for  the  creation  of  integrated  schemas  to  share  data  between 
databases;  and  (4)  has  created  a  Military  Handbook  with  a  living  electronic  index. 
The  JDBE  approach  is  reverse  engineering:  bottom  up  data  modeling  using 
existing  databases  following  the  JDBE  methodology,  creating  integrated  data 
models  from  project  data  models  by  subject  area,  and  using  these  to  interface  with 
the  top-down  CIM  Enterprise  Data  Model.  JDBE  currently  has  a  subject  area 
information  model  for  electromagnetic  equipment  characteristics,  data 
dictionary/directory  tools,  and  is  the  current  temporary  repository  for  M&S  data 
models  and  definitions.  JDBE  future  efforts  include:  extension  of  JDBE 
methodology  to  support  8320  data  standards  development  and  complex  data  types; 
refinement  of  the  data  dictionary  tool;  gathering  metrics;  and  assisting  M&S 
community  projects  in  data  modeling  and  the  use  of  IDEF1X  methodology 
through  the  ERwin  tool.  JDBE  either  is  now  or  may  in  the  future  be  supporting 
UTSS,  MICOM,  CENTCOM,  and  CCTT  projects  in  data  modeling  efforts. 
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Mr.  Rob  Wright:  Equipment  Characteristics  Data  Base  (ECDB) 

The  functional  requirements  for  the  CCTT  Equipment  Characteristics  Data  Base 
(Version  2.0)  are:  (1)  transition  to  a  windows  environment;  (2)  create  a  dynamic 
database  architecture  capable  of  handling  a  wide  array  of  equipment  identified  in 
the  CCTT  specification  Table  A-l,  handling  equipment  data  down  to  the  piece  level 
and  developing  a  common  verified  parts  master  file,  and  imported  LSAR, 
provisioning  and  IGES  data  files;  (3)  test  the  functionality  of  a  dynamic  database; 
(4)  encourage  users  to  submit  ideas  and  data  to  increase  productivity  of  the 
database;  (5)  create  data  management  and  editing  tools;  (5)  analyze  and  build  the 
A-l  parts  information  in  the  ECDB  as  the  core  data  stream;  (6)  get  confirmation  of 
Table  A-l  parts  information  from  Equipment  Program  Managers  and  Subject 
Matter  Experts;  (7)  after  confirmation,  build  and  expand  characteristics  data  files 
and  IGES  library;  and  (8)  apply  this  to  other  simulation  programs  (i.e.,  AVCATT, 
WARSIM  2000,  DIS). 

The  database  will  need  to  contain  equipment  data  for  approximately  150  weapon 
systems.  The  database  is  managed  by  FOXPRO  2.5.  This  database  links  to  other 
databases  through  the  weapon  system  name  (common  nomenclature).  Two  areas 
that  need  further  development  are:  expanding  the  data  and  doing  data  quality 
engineering.  Appendix  A  includes  the  briefing  charts  which  stepped  through  a 
very  good  demonstration  of  the  windows  interface  to  the  database  and  a  draft 
chapter  titled  “An  ECDB  Overview”. 

Mr.  Mike  Hopkins:  Update  on  CENTCOM  Conventional  Force  Database  (CFDB) 
Project 

The  mission  of  the  USCENTCOM  Combat  Analysis  Group  in  creating  the  CFDB  is 
to  research  DoD  and  service  databases;  collect  and  validate  data;  and  provide 
wargamers/analysts  with  data,  scenario  generation  tools,  and  model  interfaces. 

The  objective  of  the  Conventional  Force  Data  Base  (CFDB)  task  is  to  develop  a 
database  with  units,  personnel,  and  equipment  data  to  provide  the  modeling 
community  with  a  single  source  of  required  model  data;  reduce  model  database 
preparation  time,  and  to  check  data  accuracy.  The  units  include  data  for  all 
services,  reserve  and  national  guard,  deployable  units  and  supporting  units,  and 
units  at  the  lowest  level  reporting  personnel  and  equipment.  Personnel  data 
includes  personnel  assigned  to  a  unit  and  broken  down  by  grade  and  occupation. 
Equipment  data  is  restricted  to  equipment  appropriate  for  modeling. 

The  CFDB/Master  Simulation  Data  System  (MSDS)  work  in  the  following  way. 

The  CFDB  loads  dynamic  force  data  from  DoD  and  Services;  performs  quality 
assurance  of  data;  builds  force  structures  and  displays  unit  data;  and 
postprocesses  the  data.  The  MSDS  loads  CFDB  and  DIA  dynamic  force  data, 
builds  a  scenario  database,  translates  force  data  to  model  formats,  and  will 
process  static  characteristics  data.  The  CFDB/MSDS  has  been  in  production  since 
1989;  has  interfaces  to  CBS,  JTLS,  TACWAR,  and  JCM  models;  is  operational  in 
UNIX  and  VMS  envirnui.ir  ats;  and  provides  data  and/or  software  on  a  quarterly 
basis  to  23  sites. 

Semi-automated  data  quality  engineering  is  done  now  making  use  of  a  data 
element  dictionary,  rules,  tracking  of  data  trouble  reports,  and  human  review. 
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Data  quality  can  be  improved  by:  standardizing  data,  providing  a  problem 
reporting  process,  improving  database  W&C  checks,  enhancing  data 
administration,  and  tracking  data  element  sources  and  models.  There  are  plans 
to  provide  an  architecture  to  standardize  data  descriptions  and  data  elements  and 
an  automated  process  to  check  data  through  automated  comparisons,  rules,  math 
computations,  acceptable  ranges,  and  statistical  tests. 

Dr.  Jed  Marti:  Experiences  in  Using  Project  2851  Data 

RAND  is  working  on  an  Army  project  that  needed  to  use  Project  2851  data  for  Ft. 
Hunter  Liggett  in  JANUS  4.0  and  BDS-D  (as  well  as  other  higher  resolution  data 
such  as  DMA  ITD  and  PEGASYS  PVDB).  The  RAND  Cartographic  and 
Geographic  Information  System  (CAGIS)  already  does  a  large  number  of  data 
format  transformations  from  data  sources  (such  as  DMA  DTED,  DTAD,  and  ITD, 
PVDB,  SIF,  Landsat  and  Spot  images,  Arc/Info,  and  digitized  data)  into  output 
formats  (such  as  Arc/Info,  ASCII,  JANUS-A,  JANUS-3,  JANUS-4).  The 
transformations  they  are  currently  planning  to  implement  are  for  S1000  and 
ARTBASS  inputs  and  SIF  and  S1000  outputs.  The  JANUS  4.0  terrain 
requirements  include  the  need  for  polygonal  terrain  features,  lineal  features, 
elevation  posts,  and  buildings.  In  converting  Product  2851  SIF  data  to  internal 
CAGIS  format  they  ran  into  problems  with  polygons  with  holes,  lack  of  buildings, 
passing  multiple  attributes  with  features,  and  that  digitized  roads  and  the  culture 
map  data  they  received  were  projected  with  the  wrong  spheroid  (however  PRC 
Corporation  provided  an  easy-to-perform  correction  of  the  source  data). 

Conclusions  about  Project  2851  SIF  database  for  this  limited  task  were:  most  of  the 
format  was  easy  to  decode  and  create;  the  manual  is  excellent;  the  Application 
Programming  Interface  (API)  tools  are  incomplete;  geolocation  was  incorrect  in 
the  one  sample  used  due  to  misuse  of  spheroids  in  the  UTM  conversion;  and  two 
3D  formats  must  be  dealt  with. 

Mr.  Mike  DaBose:  Automated  Repository  for  Models  and  Simulations  (ARMS) 

The  ARMS  way  is  to  correct  the  problem  of  multiple  data  gathering  efforts  by 
providing  a  system  based  on  distribution  technology  that  acts  as  a  ringle  data 
gathering/aggregation  and  single  data  distribution  effort.  ARMS  provides  a 
common  frame  of  reference  and  is  developing  a  technology  not  a  methodology. 

A  common  frame  of  reference  means  that  all  data  (reports,  charts,  numbers,  etc.) 
can  be  reduced  to  various  “classes”  of  representation  (shapes,  numbers,  etc.).  In 
turn,  such  data  can  be  mediated  from  its  native  form  to  a  consistent  method  and 
format  of  display/transmission  to  the  user/system  within  a  given  context.  As  a 
result,  data  exchange/sharing  between  unlike  systems  becomes  efficient  and  cost 
effective. 

Using  the  definition  for  a  repository  from  the  Information  Resource  Dictionary 
System  (IRDS)  Reference  Model  Technical  Report  X3H4. 1/92-002R3,  September 
24,1992  (draft), 

“A  specialized  set  of  information  management  services  and  facilities  that 
manage  information  resources.  A  repository  system  accommodates  the 
information  management  requirements  of  an  organization,  including  the 
areas  of  information  systems  engineering  and  operation.” 
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ARMS  is  a  repository  and  distribution  technology  not  another  database.  ARMS 
reduces  redundant  data  collection,  maintains  continual  data  update,  provides 
traceable,  authoritative  data  (source  tagged)  and  enhances  current  systems 
capabilities  through  seamless  data  availability.  What  is  currently  available  in 
ARMS  is  its  portable  core  and  meta-dictionary,  the  rest  is  still  planned  or  in 
development.  ARMs  uses  object  oriented  technology,  re-usable  code,  cross 
platform  development  and  ANSI  standards/vendor  independence.  The  major 
parts  of  the  ARMS  architecture  that  have  not  been  implemented  are:  data 
collection  toolset  and  ARMS  database  mediator  and  network  accessor;  the  ARMS 
model/sim  mediators  (DIS  protocol),  ARMS  distribution  network  and  graphical 
user  interface. 

The  ARMS  system  objectives  are:  JMA  data  in  common  frame  of  reference; 
provide  Joint  M&S  data  for  NWTDB;  distribute  NWTDB  standards  to  the 
community;  provide  a  roadmap  for  goal/objective  architectures;  centralized 
configuration  control  and  repository  management;  distributed  data  gathering; 
repository  of  "lessons  learned”;  and  joint  doctrine  statements.  (Aside:  it  is 
unclear  who  the  community  is  that  is  being  served  and  that  configuration  control 
and  repository  management  are  being  performed  for.) 

The  ARMS  programmatic  objectives  are:  vendor  independence;  provide  current 
and  future  platforms  data  for  future  assessment  process;  incorporate  Enterprise 
Model  functions,  processes,  and  data  models;  incorporate  an  object  oriented 
DBMS  (COTS);  establish  a  data  “clearing  house”  for  electronic  distribution  to 
models,  simulations,  and  users;  and  provide  standardized  data  elements  as 
determined  by  responsible  authority  to  support  Joint  interoperability.  The  benefit 
of  ARMS  will  be  to  provide  analysts  with  a  single  authoritative  source  of  common 
format  data  for  platform  and  systems  information  (red/white/blue)  and  other  data 
(including  simulations,  wargames,  architecture  drawings,  network  and 
communication  structures,  documentation,  characteristics  of  performance, 
effectiveness  data,  probability  of  kill). 
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4.  DATA  W&C  TASK  FORCE  MEETING  NOTES 


4.1  AGENDA 


Monday,  February  14, 1994 
PRESENTATIONS 

0830-0900  Discussion  of  Objectives  for  Data  W&C  Group  and  Summary  of 
Data  W&C  Working  Group  Results  from  MORS  SIMDAT: 

Ms.  Iris  Kameny 

0900-0930  Interaction  and  Interdependencies  of  Analysis,  Models,  and  Data: 

Ms.  Simone  Youngblood 

0930-1000  CENTCOM  Experience  with  Source  Data  Problems: 

Mr.  Mike  Hopkins 

1000-1030  Discussion  of  Data  quality  Concepts:  Mr.  Jeff  Rothenberg 

1030-1100  Break 

1100-1200  Discussion 

1200-1300  Lunch 

1300-1700  Discussion: 

—  Send  potential  discussion  topics  to  Iris  Kameny 
kameny@rand.org,  phone:3 10/393-04 11,  x7174 

fax:  310393-4818 

—  Topics  will  also  be  collected  during  morning  briefings  and 
prioritized  for  discussion 
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4.3  DATA  W&C  ISSUE  DISCUSSION 


Ms.  Iris  Kameny:  Suggested  Objectives  for  Data  W&C  and  Summary  of  Results 
from  MORS  SIMDAT  Data  W&C  WG 

Iris  Kameny  opened  the  session  by  presenting  her  suggested  objectives  for  Data 
W&C.  As  she  proceeded  through  the  first  chart,  there  was  much  discussion  and 
additional  subjects  were  added  as  discussed  in  the  following  paragraphs. 

Under  "develop  guidelines  for  Data  W&C,”  the  TF  wanted  to  make  sure  that  this 
included  cost  models  and  cost  information. 

Under  "address  authoritative  data  sources  and  their  responsibilities,”  it  was  noted 
that  this  should  include  the  authority  to  certify  another  organization’s  data.  An 
example  offered  by  the  AMSAA  people  was  that  they  certify  most  of  the  data 
produced  by  the  TRAC  TADS  data  center  to  feed  Aimy  models.  They  certify  the 
data  derived  from  the  data  they  furnish  to  TADS.  This  generated  some  discussion, 
since  many  of  the  TF  members  seemed  to  believe  that  data  centers  adding  value  to 
data  would  have  the  responsibility  of  certifying  what  they  had  done.  This  will  need 
more  exploration  and  perhaps  a  broader  perspective  to  include  several  options  as 
long  as  the  certification  authority  and  process  is  made  clear. 

No  changes  to:  "Address  the  role  of  M&S  data  centers  between  data  sources  and 
simulation  applications” 

Question:  should  we  address/distinguish  between  metadata  and  data?  (Iris 
recently  joined  a  metadata  working  group  — at  least  over  email —  and  will  share 
some  of  their  ideas  with  the  Data  W&C  group  in  the  near  future.  An  IEEE 
metadata  WG  is  just  starting  up  also.) 

Iris’  briefing  went  on  to  discuss  the  guidelines  for  Data  W&C  as  including 
definitions,  description  of  tools  and  methods  for  V&V,  definition  and  development 
of  a  certification  profile  of  metadata  that  would  describe  the  quality  of  a  database, 
and  developing  policies  and  procedures  for  performing  data  W&C  and  relating  it 
to  M&S  W&A.  There  was  a 'suggestion  to  add:  "management  of  the  W&C 
process”  to  the  list  of  activities  under  developing  guidelines  for  W&C.  There  was 
a  question  as  to  whether  separate  W&C  guidelines  are  needed  for  near-term  and 
long-term?  (for  example  with  respect  to  data  standards). 

She  suggested  that  in  considering  the  roles  of  M&S  centers  we  include 
considering  them  as  authoritative  sources,  in  their  sharing  and  reuse  of  data, 
and  also  the  need  for  some  organization  keeping  track  of  the  centers,  their 
missions,  and  encouraging  communications  between  them. 

Iris  then  went  over  the  results  from  the  MORS  SIMDAT  Data  W&C  working 
group  especially  the  definitions  of  W&C  which  the  TF  decided  would  be 
addressed  in  the  afternoon  discussion  session. 

Mike  Barton  (AMSAA)  offered  that  AMSAA  has  guidelines  for  certification  since 
they  have  a  red  team  look  at  data.  The  TF  would  like  more  information  about  this. 
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A  point  was  made  that  the  DODD  5000.59  levies  the  responsibility  for  data  W&C 
on  the  Services. 

Mr.  Mike  Hnpkins:  CENTCOM  Experience  with  Source  Data  Problems 
Mike  went  over  in  detail,  the  kinds  of  source  data  problems  they  have  run  into 
(using  the  same  viewgraphs  from  the  I/DB  main  meeting).  He  noted  that  they  will 
be  sharing  their  data  with  NRaD  in  the  future.  The  current  CFDB  database 
contains  over  13  million  records  and  12,000  fields.  The  Marine  HQ  data  quality 
engineering  (DQE)  effort  addresses  source  data  problems.  The  method  is  to  check 
source  data  against  the  data  element  dictionary  using  rules  defined  by  the  Data 
Base  Administrator.  This  begins  to  automate  some  of  the  process  they  were  doing 
by  having  the  human  read  through  instance  data.  When  they  find  errors  in  the 
source  data,  they  need  to  go  back  to  the  source  with  a  report  since  the  source  has  to 
change  or  confirm  the  changes  to  the  data.  They  plan  to  produce  better  data  by: 
developing  data  standards,  automating  the  problem  reporting  process,  improving 
the  database  W&C  checks,  enhancing  the  role  of  data  administrator  and  tracking 
data  sources. 

Mike  stressed  that  W&C  procedures  need  to  address  missing  data,  subject  area 
experts  developing  rules,  and  domain  constraints  expressed  as  part  of  the  data 
element  standard  descriptions.  CENTCOM  responded  to  the  DMSO  focus  call 
with  a  "Database  System  Upgrade"  project.  DQE  was  the  biggest  piece  of  that 
effort.  Their  definition  of  quality  includes  completeness  of  the  dataset  as  a 
characteristic  since  they  often  discover  data  is  missing. 

Ms.  Simone  Youngblood:  Interaction  and  Interdependencies  of  Analysis,  Models, 
andData 

(Simone  Youngblood  gave  the  same  briefing  that  she  and  Dale  Pace  gave  at  the 
Data  W&C  WG  at  the  MORS  SIMDAT  Symposium  and  I  have  included  my 
writeup  from  those  proceedings  as  well  as  their  brief  on  W&C  costs.) 

Good  analysis  can  produce  insights  and  meaningful  results  in  spite  of  model  and 
data  limitations.  They  suggested  acceptance  of  SIMVAL/DoD  M&S  Directive 
Definitions  for  model,  simulation,  W&A,  and  certification.  Issues  included 
license  of  the  analyst  to  manipulate  Input  data  and  M&S  parameters  for  analytic 
purposes,  and  the  credibility  of  analysis  when  drawing  conclusions  from  use  of 
inadequate  data  and/or  tools.  Observations  were  that:  quality  and  capabilities  of 
M&S  tools  have  increased  significantly;  availability  of  data  has  increased  and 
"live”  data  may  be  mixed  with  simulation  data;  the  appropriateness  of  the  analytic 
process,  M&S  tools,  and  associated  data  has  received  some  recent  attention;  and 
value  of  analysis  can  be  limited  by  the  model  and/or  the  data.  The  conclusions  are 
that  the  interaction  of  analysis-model-data  must  be  appreciated  but  current 
W&A/C  efforts  do  not  do  so  adequately  and  that  end  use  requirements  focus  can 
lead  to  economies  in  data/model  resources  (e.g.,  fidelity  level  driven  by  analysis 
plan). 

Verification,  Validation,  Accreditation  and  Certification  Costs:  Ongoing  V&V 
costs  are  in  the  development  and  implementation  of  V&V  plans  and  in  the 
performance  of  V&V  at  all  levels  of  M&S  development.  Problems  with  cost 
include:  limited  historical  cost  data,  lack  of  management  appreciation  of 
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W&A/C  value,  lack  of  V&V  foundation  upon  which  to  build,  and  legacy  models 
are  less  supportive  of  the  W&A  processes.  Costs  are  dependent  on  size  and  type 
of  M&S,  data  availability,  level  of  confidence  required,  time/resources  available, 
and  application.  V&V  costs  may  be  reduced  by  detecting  errors  early  in  the  M&S 
development  phase,  using  modem  software  engineering  practices,  and  use  of 
automation  tools  (e.g.,  data  modeling  and  visualization  tools).  Software  IV&V  is 
typically  2%  -  18%  of  total  development  and  levels  of  M&S  accreditation  can  vary 
from  a  few  man  weeks  to  man  years  dependent  on  the  need  and  funding.  There 
are  many  consequences  in  not  performing  W&A/C  adequately  but  not  enough 
cost  data  has  been  collected  to  quantify  V&V  cost  benefits.  They  suggested  that 
projects  involved  in  W&A/C  begin  to  accumulate  and  publish  cost  information; 
that  projects  begin  the  V&V  process  as  early  as  possible  to  reduce  M&S  costs;  and 
that  W&A/C  become  institutionalized  as  a  normal  part  of  M&S  development 


Discussion: 

The  Navy  ARMS  product  looked  at  the  data  requirements  for  M&S  and  found  that 
some  of  the  data  is  input  to  M&S  and  other  is  embedded  in  models.  This  poses  a 
problem  for  data  W&C 

There  is  also  an  issue  with  how  to  verify  live  data. 

Someone  noted  that  DoDD  5000.59  says  there  must  be  guidelines  for  data  as  part  of 
the  W&A  process. 

There  was  a  good  suggestion  that  we  send  out  a  formal  request  through  the  M&S 
offices  of  the  Services  and  DoD  agencies  for  cost  benefit  information  regarding 
data  W&C. 

John  Griffiths  voiced  a  need  to  turn  a  model  into  a  deterministic  model  at  the 
limits.  When  doing  model  W&A,  there  is  a  need  to  perform  sensitivity  tests  of 
the  model  when  the  data  parameters  are  set  to  the  limits. 

Mr.  Jeff  Rothenberg:  Discussion  of  Data  Quality  Concepts: 

Data  is  the  result  of  data  modeling  of  the  real  world  which  produces  some 
particular  (abstract)  view  among  many  possible  views  of  reality.  Concretely,  data 
in  a  database  is  a  representation  of  a  data  view  of  the  real  world  in  some  format. 
Many  alternative  representations  are  possible  corresponding  to  different  data 
models/formats.  Every  representation  is  a  model  of  the  abstract  data.  Data 
“quality*  is  really  referring  to  the  suitability  of  data  for  a  particular  purpose  or 
range  of  purposes.  It  may  be  useful  to  think  of  this  as  its  suitability  for  a 
particular  “customer”  or  analysis/M&S  purpose.  We  can  promote  data  quality  by 
recording  sufficient  metadata  about  data,  by  performing  explicit  W&C  on  data 
(testing  and  evaluating  and  recording  results)  and  by  controlling  and  improving 
the  processes  that  affect  the  data  in  such  a  way  as  to  improve  the  data  quality. 

Quality  is  represented  by  metadata  at  three  levels:  the  database  level,  the  data- 
element  level  (data  dictionary)  and  the  data-value  level.  Jeff  noted  that  one  may 
need  data-element  and  data-value  level  meta-metadata  (data  about  the  metadata) 
and  that  inheritance/defaulting  of  metadata  may  reduce  redundancy  and  the  size 
of  a  metadata  database.  The  database  level  metadata  can  be  categorized  into 
general,  characterization  metadata,  quality  measures,  process  control 
information  and  W&C  audit  trail.  The  data-element  level  metadata  can  be 
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categorized  into:  meaning  of  the  data  element;  source  and  generation-cycle 
information;  completeness,  constraints  and  relationships  to  other  data/databases; 
domain/datatype  and  units-of-measure;  resolution,  precision,  intended/expected 
accuracy;  and  W&C  audit  trail.  The  data  value  level  metadata  can  be 
categorized  into  quality,  annotation,  source  information,  next-source  information, 
transformation  audit  trail,  and  W&C  audit  trail.  A  certification  profile  can  be 
composed  from  the  W&C  audit  trail  metadata  from  all  levels. 

Jeff  suggested  the  following  first  steps  toward  data  qualify:  identify  a  candidate 
database  for  a  "pilot”  data  quality  project  and  outline  the  data  quality  procedures 
for  the  chosen  database.  An  interesting  question  is  whether  we  can  afford  to 
improve  data  quality,  how  much  does  W&C  cost?  Or,  can  we  afford  NOT  to 
improve  data  quality? 


Discussion: 

ARMS  project  and  NWTDB  will  be  doing  a  survey  of  M&S  data  needs  and  it  was 
suggested  that  the  survey  information  could  be  captured  in  entries  into  the  M&S 
Directory.  Navy  and  ARMS  is  trying  to  consolidate  support  for  M&S  data  instead 
of  having  independent  projects  collecting  the  data. 

It  was  pointed  out  that  there  was  a  need  for  a  directory  of  authoritative  data  sources. 

An  issue  was  identified  about  updates  to  derived  data  and  how  to  show  this  in 
quality  characteristics.  Is  it  shown  as  delta  changes?  Some  data  may  not  be 
updated  until  it  is  used.  Also  investigate  whether  different  metadata  is  needed  to 
describe  historical  databases  then  current  databases. 

There  was  discussion  of  a  pilot  study.  The  FY93  CENTCOM  project  that  involved 
DQE  was  a  proof  of  concept  for  CENTCOM.  Another  suggestion  was  that  an 
unclassified  database  be  selected  perhaps  in  the  healthcare  area.  An  idea  was  to 
use  one  or  more  databases  that  cut  across  the  greatest  number  of  users  for  the 
greatest  impact. 

Discussion  of  cost  issues  resulted  in  Walt  Swindell  showing  us  a  few  TADS 
viewgraphs  that  indicated  that  automation  and  DQE  by  TADS  resulted  in 
reducing  the  staff  by  50%  and  accomplishing  10  times  the  amount  of  work.  On  the 
TADS  system,  the  network  server  performs  access  control.  TADS  checks: 
preloaded  systems  for  correctness,  data  for  anomalies,  and  the  derived  data  it 
creates  for  anomalies.  The  TADS  loader  edits  the  database,  archives  it,  and 
checks  for  anomalies.  The  TF  asked  TADS  and  CENTCOM  for  any  additional  cost 
benefit  information  related  to  data  V&V  they  could  provide. 

Dave  Danko  (DMA)  gave  Iris  a  copy  of  the  draft  “Content  Standards  for  Spatial 
Metadata”  which  was  produced  by  the  FGDC  Standards  Working  Group  on 
January  27,  1994.  A  copy  is  included  in  this  proceedings.  This  effort  was  done 
jointly  by  the  Census  Bureau,  USGS,  the  Forestry  Service  and  DMA.  The  group 
was  formed  because  they  needed  a  metadata  outline  to  be  able  to  see  who  is  doing 
what.  They  had  tried  sharing  information  through  the  internet  WAIS  but  used 
different  names  for  the  metadata  concepts  and  it  didn’t  work.  DMA  wants  to  give 
people  the  metadata  descriptions  along  with  procedures  for  vising  them. 
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Afternoon  Discussion: 

The  TF  decided  on  definitions  for  W&C  as  shown  below.  A  copy  of  these  were 
given  to  Pat  Sanders  for  the  M&S  WG. 

DATA  VERIFICATION:  The  use  of  techniques  and  procedures  to  ensure  that 
data  meets  constraints  defined  by  data  standards  and  business  rules  derived  from 
process  and  data  modeling,  and  that  data  values  for  input  to  the  intended  M&S 
conceptual  and  logical  design  are  transformed  and  formatted  properly. 

DATA  VALIDATION:  The  review  of  data  by  subject  area  experts  and  its 
comparison  to  known  or  best-estimate  values  as  appropriate  for  an  intended  M&S 
conceptual  and  logical  design. 

DATA  CERTIFICATION:  Determination  that  data  have  been  verified  and 
validated  as  appropriate  for  the  intended  usage. 

4.4  SUBGROUP  ORGANIZATION 

The  TF  decided  to  form  two  subgroups:  one  to  address  Guidelines  for  Data  W&C 
and  the  other  to  address  Authoritative  Data  Sources  and  Centers 

Guidelines  for  Data  W&C:  a  major  task  will  be  to  define  a  certification  profile  for 
a  database  that  will  describe  its  data  quality  characteristics  including  verification 
and  validation  methods  used.  The  profile  will  be  necessary  for  database 
certification. 

Members: 

Bob  Hartling  (Navy)  co-chair 

Mark  Ralston  (Army/AMSAA)  co-chair 

Joe  Brock  (DISA/JIEO) 

Dave  Danko  (DMA) 

John  Freeman  (STRICOM) 

Mike  Hopkins  (CENTCOM) 

(Iris  Kameny  (RAND)) 

Ray  Miller  (Air  Force  XOMT) 

Jeff  Rothenberg  (RAND) 

Eleanor  Schroeder  (Navy) 

Simone  Youngblood  (JHU/APL) 

TRAC  (DIS  representative)  ? 

Authoritative  Data  Sources  and  Data  Centers:  will  identify  Component 
authoritative  M&S  data  sources,  define  their  responsibilities  to  the  M&S 
community,  and  identify  and  define  the  roles  of  M&S  data  centers  that  get  data 
from  authoritative  sources  and  prepare  data  for  input  to  models. 

Members: 

Bill  Dunn  (Army/AMSMO)  co-chair 
Mike  Hopkins  (CENTCOM)  co-chair 
Jim  Augins  (consultant/Navy  ARMS) 

Dave  Danko  (DMA) 
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LCDR  Flax  (Navy/ARMS) 

John  Freeman  (STRICOM) 

Bob  Hartling  (Navy) 

Dan  Hogg  (J8)  ? 

(Iris  Kameny  (RAND)) 

Ray  Miller  (Air  Force  XOMT) 

Eleanor  Schroeder  (Navy) 

Walt  Swindell  (Army/TRAC/TADS) 

JIEO/CIM  n 
DLA  V. 

CCTT  ?? 

UTSS?? 

V.  Question  marks  indicate  a  desire  to  get  participation  from  these  organizations 
4  JL  FUTURE  MEETINGS 

March  22,  1994  Data  W&C  Guidance  Subgroup  Meeting  (at  IDA  Room  119). 

Goals  are:  (1)  finalized  versions  of  the  definitions  for  Data  W&C,  (2)  a  proposal 
for  conducting  joint  Data  W&C,  and  (3)  a  compilation  of  tools  and  techniques  for 
ensuring/measuring  data  quality. 

April  1,  1994  Authoritative  Data  Sources  and  Data  Center  Subgroup  milestone: 
first  cut  to  compile  the  Services  and  joint  elements  efforts  to:  (1)  provide  agency 
names  and  responsibilities  of  the  authorized  (or  perceived  as  authorized)  data 
sources  as  necessary  according  to  mission  functionality  (e.g.,  terrain,  weather), 
level  of  resolution  (e.g.,  engagement,  campaign,  theater),  and 
customer/applications.  What  criteria  constitute  an  authoritative  source?;  (2) 
provide  agency  names  and  responsibilities  of  data  centers  along  with  the 
customers  and  functionality  they  serve,  (3)  address  sharing  and  reusing  of  data 
between/among  these  data  sources  and  centers,  and  (4)  address  responsibilities  of 
data  customers. 


April  19, 1994  W&C  Task  Force  Meeting  at  IDA  (0800  -  01700) 


5.  DATA  STANDARDS  TASK  FORCE  MEETING  NOTES 


5.1  AGENDA 


FEBRUARY  17, 1994. 

The  Data  Standards  Task  Force  will  spend  the  day  discussing  areas  of  focus  for 
itself  and  attempt  to  identify  a  project  that  it  can  undertake  to  support  data 
standards  in  the  M&S  community. 


Participants  are  encouraged  to  propose  ideas  prior  to  the  meeting  to  Twyla 
Courtot  (courtot@mitre.org,  or  voice  (703)  883-7343). 
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Roy  Scrudder  CSC-JDBE  (602)  538-4933  (602)  538-4812  scrudder9huachuca-emhl7.army.mil 

Omar  Spaulding  NASA  (202)  358-3098  (202)  358-0777  ospaulding9mtpe.hq.nasa.gov 

Walt  Swindel  TRAD0C  (913)  684-3866  (913)  684-3030  swindelw9tracer.army.mil 

P.  Valentine  USAEPG/JDE  (602)  538-4973  (602)  538-4976  valentinep9huachuca-emhl7.army.mil 

Rob  Wright  RCI  (407)  658-9541  (407)  282-1451  wright9dmso.dtic.dla.mil 


&3  DATA  STANDARDS  ISSUES  DISCUSSION 


What  should  this  group  be  focused  on?  There  is  a  preponderance  of  M&S  data  that 
comes  from  other  functional  areas  or  places.  Most  M&S  data  is  derived. 

Augins:  There  may  be  some  standards  we  need  that  are  not  being  addressed  by 
other  groups.  ANSI  X3L8  has  put  forth  a  family  of  data  standards  and 
guidelines.  This  can  be  used  as  a  starting  point.  We  need  standard  data 
definition  attribute  standards,  meta  metadata  standards,  and  standards  for 
exchange  of  metadata  and  diagrams. 

Valentine:  With  respect  to  IDEF1X,  they  are  developing/need  a  data  interchange 
language. 

IRDS  has  been  replaced  by  PCTE.  The  CDIF  standard  is  beginning  to  allow  the 
interchange  of  diagrams. 

Haeker.  With  respect  to  DIS  standards.  What  is  our  scope: 

(1)  8320,  data  elements  and  data  modeling 

(2)  interoperability:  M&S  talking  to  each  other  through  PDUs 

(3)  Capturing  central  data  provider  information 

(4)  Capturing  M&S  data  users:  what  do  models  require  and  who  finds  them  and 
gets  them  modernized 

(5)  library  concepts:  data  in  library,  information  analysis  center,  catalogs 

(6)  information  sharing,  demos,  communicate  to  the  world  as  to  where  we  are 
going 

Standard  and  authoritative  data  sources  can  alleviate  data  redundancy:  about  the 
worst  example  of  duplication  that  Haeker  has  seen  are  the  three  shops  doing 
weather:  Air  Force,  Navy  and  Army. 

Dr.  Anita  Jones  wants  DMSO  to  concentrate  on  standards  for  data  about  smoke, 
who  games  it  and  what  do  they  need  wrt  smoke,  terrain,  weather 

Valentine:  There  are  three  different  kinds  of  standards 
— 8300  series  data  standards 
— standard  data  models:  Army,  Enterprise 
— standardized  data 

Huo:  We  need  to  support  Anita  Jones  in  authoritative  sources  of  data 

Haeker:  The  role  of  this  task  force  should  be  facilitating:  pulling  Services  together 
on  weather,  forcing  CDIF  standards  to  be  what  we  want 

Augins:  We  need  to  get  requirements  out  there,  we  need  to  set  our  priorities. 

Courtot:  CDIF  has  a  prototype  for  exchange,  what  about  a  small  group  forming  to 
evaluate  and  test  it?  How  does  a  TF  get  work  done  voluntarily?  Courtot  supports 
breaking  the  large  TF  into  sub-groups. 
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Griffiths:  Some  models  that  are  outside  DoD  use  databases  that  are  highly 
classified.  We  want  standards  for  M&S,  the  DoD  community  is  driving  the  rest  of 
the  world  in  data  standards  and  M&S 

Twyla  asked  each  person  to  tell  what  their  interests  were  in  data  standards  and 
the  current  work  they  were  doing  related  to  data  standards.  While  they  were 
speaking  Twyla  made  an  outline  on  the  white  board. 
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Coordination  of  Standards  Development 
CDIF  OME/A3H7 

SQL  across/within  DoD 

DIS 

Models 

generic  vs  specific  (lessons  learned,  focus) 

underlying  database  (IDEF1X  modifications,  standards/guidelines) 

Requirements 

data/sources  tools 

Repository 

conformance  testing 
interchange  mechanism 
contents/tools 

Standard  Libraries  (sources) 

Classification 

Discussion: 

Question:  How  will  the  results  of  the  standards  TF  be  brought  to  the  M&S  WG? 
Answer:  the  M&S  FDAd  will  present  the  TF  agenda  to  the  M&S  WG 

NASA  is  putting  out  grants  to  get  ideas  geared  toward  networking,  and 
development  of  tools  by  giving  organization  funds  (e.g.,  universities  working 
within  the  community)  to  develop  tools  and  get  them  into  community  and  bring 
users  in  and  create  needs.  They  will  be  giving  a  second  set  of  grants  that  will  be 
joint  ventures  between  government  and  private  organizations  to  drive  things  to  be 
developed.  We  could  look  at  this  for  DMSO  for  FY95,  identify  those  areas  worthy  of 
funding  to  support  the  infrastructure.  Data  standards  may  be  one  of  these  areas, 
look  at  this  method. 

Expressed  need  to  keep  up  document  references  on  the  I/DB  bulletin  board  so 
people  will  know  what  standards  documents  are  the  latest  ones. 

The  Data  Standards  Task  Force  made  specific  assignments  to  several  members 
and  identified  at  least  one  subgroup: 

*  What’s  Available  and  Where:  Peter  Valentine  (Army/JDBE) 

*  Coordination  of  Data  Standards  Across  and  Within  DoD:  Lud 
Haddad  (Army  CCTT) 

*  Data  Model  Interchange  Standards:  Jim  Augins  (consultant  for 
Navy  ARMOR) 

*  Generic/Specific  Data  Models  and  Lessons  Learned:  Roy  Scrudder 
(Army/JDBE) 
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•  Reuse  Library  Framework  (RLF):  Lud  Haddad  (Army  CCTT) 

A  Repository  subgroup  was  formed  to  look  into  DDRS  issues  and  also  examine  the 
IRDS  standard  in  light  of  government  implementation.  Data  interchange  will 
also  be  addressed.  The  Repository  subgroup  had  a  meeting  Thursday,  Feb  17, 
after  the  I/DB  broke  up  to  discuss  Jeff  Wolfe’s  DIRS  project. 

Members  are: 

Jim  Augins  (consultant  to  Navy  ARMOR)  co-chair 

Peter  Valentine  (Army/JDBE)  co-chair 

Carl  Carden 

Dave  Danko 

Mike  Frame 

Lud  Haddad 

Scott  Kinser 

Dan  Lewis 

Kent  Manley 

Emily  McCoy 

Chris  Olson 

Jim  Santangelo 

Eleanor  Schroeder 

Omar  Spaulding 

Jim  Watson 

Jeff  Wolfe 

Rob  Wright 

Interest  in  a  database  security  was  expressed  by  John  Griffiths,  Mike  Rybacki, 
and  Twyla  Courtot 

5.4  FEBRUARY  17  MEETING 

February  17,  Meeting  of  Repository  Subgroup:  action  item:  get  an  account  for  a 
bulletin  board  so  members  can  describe  what  they  are  doing  related  to  repositories 
and  describe  their  short  term  needs  and  suggestions  as  to  solutions  (do  this 
within  2  weeks).  Repositories  indude:  IRDS  FIPS  156  systems,  places  to  keep 
IDEFO,  and  IDEF1X  models,  and  data  standards,  etc. 

April  20,  Meeting  of  the  Data  Standards  Task  Force  at  IDA 
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6.  COMPLEX  DATA  TASK  FORCE  MEETING  NOTES 


6.1  AGENDA 


FRIDAY,  FEBRUARY  18,  1994 

REPORT  ON  ISSUES  IDENTIFIED  DURING  LAST  MEETING 

0800-0830  Report  on  definition  of  complex  data  and  the  categories  of  complex 
data  to  include  multi-valued  attributes/repeating  groups  and 
derived  data  (should  also  include  results  from  MORS  SIMDAT 
Mini-Symposium):  Mr.  Peter  Valentine 

0830-0900  Interoperability  and  Data  Exchange:  Dr.  Miro  Medek 

0900-0930  Defense  Information  Repository  System  (DIRS)  Data  Model: 

Mr.  Jeff  Wolfe 

0930-1000  Break 

1000-1030  Report  on  DoD  Data  Standardization  and  Data  Reuse  Guidance  for 

Complex  Data  Elements  (Draft):  Mr.  Duane  Hufford 

1030-1100  Hard- Wired  Data  Hierarchies:  The  Tyranny  of  End-Use  Specific 

Representations:  Jack  Sheehan,  ARL,  Univ.  of  Texas 

1100-1200  Spatial  Data  Standardization  Data  Model:  Dr.  Jack  Teller 

1200-1300  Lunch 

1300-1330  Pilot  Studies:  e.g.,  CCTT,  UTSS,  CENTCOM,  several  of  which  are 
considering  JDBE  help:  Ms.  Iris  Kameny 

1330-1630  Discussion: 

—  Send  potential  discussion  topics  to  Iris  Kameny 
kameny@rand.org, phone:  310/393-0411,  x7174 

fax:  310/393-4818 

—  Topics  will  also  be  collected  during  morning  briefings 
and  prioritized  for  discussion 
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&3  COMPLEX  DATA  ISSUES  DISCUSSION 

Iris  Kameny  started  off  the  meeting  by  reviewing  the  action  items  from  the  October 
28th  meeting  and  noted  that  two  identified  issues,  audit  trails  and  tagging  instance 
data,  are  topics  that  will  be  covered  by  the  new  W&C  Task  Force.  She  reiterated 
the  Complex  Data  Task  Force  (CDTF)  long  term  goals:  of  providing  categorization  of 
complex  data  types  and  developing  a  guideline  to  data  modeling  and 
standardization  of  complex  data  types  for  the  M&S  community.  The  near-term 
goals  are  to  perform  pilot  studies  in  complex  data  models  and  standards  and 
coordinate  with  CIM  on  issues,  problems  and  suggested  extensions  to  IDEF1X  and 
8320.1-M-l.  She  presented  a  series  of  viewgraphs  showing  different  categorizations 
of  complex  data  from:  MORS  SIMDAT,  Duane  Hufford’s  DoD  draft  document, 
JDBE,  and  RAND. 

The  briefs  from  Peter  Valentine  on  definition  of  complex  data  and  from  Miro 
Medek  on  interoperability  and  data  exchange  were  action  items  from  the  October 
28th  meeting.  Jeff  Wolf,  Duane  Hufford,  and  Jack  Teller’s  briefs  were  invited 
reports  on  projects  relevant  to  complex  data.  Jack  Sheehan’s  brief  was 
volunteered. 

Mr.  Peter  Valentine:  Complex  Data  Definition 

Definition  "Complex  Data  is  that  data  which  is  not  easily  represented  using 
existing  data  modeling  methodologies.”  Current  data  models  can  be  very 
complex,  an  example  is  that  IDEF1X  categories  are  complex  compared  to  Chen  E- 
R  diagrams.  Structures  such  as  hierarchies  or  directed  graphs  are  called 
complex  even  though  they  can  be  represented  (though  with  difficulty).  Non¬ 
standard  data  types  (like  graphics  and  sound  are  called  complex). 

IDEF1X  represents  the  DoD  selected  methodology  for  data  modeling  as  part  of  the 
DoD  data  standards  program  and  is  the  methodology  being  addressed  in  this  TF. 

We  can  represent  complex  data  as  falling  into  one  of  two  types  of  basic  shortfalls  to 
IDEF1X:  those  that  are  addressable  through  the  use  of  tricks  of  representation, 
and  those  that  are  unaddressable  unless  the  IDEF1X  language  is  extended  or 
there  is  an  external  supplementation  to  the  data  model. 

Complex  data  that  can  be  handled  by  addressable  shortfalls  to  IDEF1X  include: 
recursive  structures  like  lists  and  hierarchies,  composite  attributes  (groups), 
complex  data  types  (BLOBs,  arrays,  binary,  etc.),  repeating  groups  (multiple 
values),  and  multi-purpose  (different  meanings). 

Peter  showed  how  a  chain,  list,  hierarchy,  binary  tree,  and  directed  graph  could 
be  modeled  in  IDEF1X.  He  noted  that  complex  attributes  can  be  represented  as 
“group”  attributes  supported  by  a  state-of-practice  feature  available  in  some 
IDEF1X  tools.  This  is  an  issue  being  addressed  by  the  IEEE  IDEF1X  WG. 

He  suggested  that  complex  data  types  (BLOBS,  graphics,  sound,  compound 
documents)  can  be  addressed  by  separately  modeling  the  data  type  using  IDEF1X 
or  other  techniques  such  as  Jackson  Diagrams;  that  these  objects  can  be 
physically  represented  in  existing  RDBMSs  as  BLOB,  IMAGE  or  MEMO  fields; 
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and  that  one  can  also  use  state-of-practice  user  defined  data  types  to  define  them. 
(He  showed  an  example  of  image  and  pixel  in  a  part-whole  relationship.) 

Repeating  groups  are  not  a  valid  IDEF1X  construct  but  can  be  easily  addressed  by 
creating  another  entity  to  contain  the  repeating  values. 

For  multi-purpose  attributes  (attributes  whose  meaning  changes  based  on 
changes  in  the  instance  values)  there  are  no  IDEF1X  language  constructs 
because  this  violates  data  normalization  rules.  He  notes  that  these  occur  in  as-is 
models  and  can  be  documented  in  the  Glossary  description  of  IDEF1X. 

Complex  data  unaddressable  by  IDEF1X  includes:  derived  data  (algorithms, 
aggregates/summaries),  complex  business  rules,  objects  (with  methods),  data 
dependencies  (model  level  and  instance  level),  and  physical  representation  of  bits 
and  bytes. 

He  noted  that  the  IEEE  IDEF1X  WG  is  working  toward  a  formal  language  for 
documenting  complex  business  rules  (those  not  already  handled  as  business 
rules  in  IDEF1X)  and  maintaining  them  in  the  Glossary.  They  are  also 
addressing  objects  particularly  issues  of  object  identity  and  persistence.  The 
important  question  is  whether  different  data  modeling  methods  are  needed  to 
represent  objects  and  complex  business  rules.  Derived  data  and  data 
dependencies  require  some  way  of  relating/tracking  data  to  the  data  participating 
in  the  derivation  as  well  as  the  derivation  processes. 

An  issue  that  Peter  posed  is  where  does  data  leave  off,  should/when  does  data 
need  to  include  process?  What  is  the  scope  of  data? 

Dr.  Miro  Medek:  Interoperability  and  Data  Exchange 

Data  sharing  in  the  DMSO  community  must  overcome  heterogeneity  in  models, 
data,  hardware,  and  software.  For  data  exchange,  data  standardization  should 
reduce  the  problem  of  translating  shared  data.  Data  translation  involves:  data 
semantics  (Boolean  to  T,F),  data  representation  (miles  to  meters),  data  types 
(complex  to  primitive).  Data  conversion  involves  data  organization  and  structure, 
and  data  format.  Miro  showed  a  target  architecture  based  on  data 
standardization  where  the  sources  collect/generate  standardized  data,  the  models 
use  standardized  data  and  there  is  a  data  exchange  standard  that  they  all 
recognize  and  use.  In  his  evolutionary  migration  view,  modifications  have  been 
made  to  the  model  to  enable  it  to  use  standard  data  and  to  the  source  that  provides 
standard  data.  In  addition,  translation  is  required  between  a  data  source  that 
provides  nonstandard  data  and  the  data  exchange  standard  and  between  the 
model  that  uses  nonstandard  data  and  the  data  exchange  standard.  Migration 
strategies  must  consider  time,  budget,  resources,  data  ownership,  and  technology 
insertion. 

The  repository  plays  a  role  in  data  translation/conversion  b>  containing 
information  about  location  of  data,  format  and  representation  of  source  data, 
algorithms  for  converting  data,  and  translation  algorithms  for  translating  data  to 
the  required  representation.  The  description  of  translation  algorithms  in  the 
repository  should  contain  definitions  of  input,  translation  output,  algorithm,  and 
source  code  (if  available). 
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There  is  an  issue  in  the  M&S  community  with  finding  data  that  doesn’t  exist  in 
the  required  form  but  needs  to  be  derived  from  existing  data  and  an  algorithm. 

An  issue  is,  under  what  conditions  is  this  information  put  into  the  repository  for 
reuse.  How  much  reuse  must  one  expect  in  order  to  make  this  cost  beneficial. 
Attention  also  needs  to  be  paid  to  being  able  to  rapidly  locate  such 
descriptions/algorithms  once  they  have  been  entered. 

(It  was  noted  that  this  brief  did  apply  more  to  the  newly  formed  Repository 
subgroup  of  the  Data  Standards  Task  Force  than  to  the  CDTF.) 

Mr.  Jeff  Wolfe:  Defense  Information  Repository  System  (DIRS) 

An  objective  of  the  DIRS  project  is  to  produce  standard  data  for  managing  data 
(sort  of  meta  metadata).  DIRS  is  a  life  cycle  model  for  customers  having  a  need  to 
share  data  assets  at  the  enterprise  level  across  DoD.  Now  there  are  many 
different  nonstandard  repositories  in  the  CIM  community  and  in  the  functional 
areas  and  Components.  The  hope  is  that  DIRS  will  replace  all  these  piecemeal 
repository  efforts. 

IRDS  takes  a  broad  look  at  the  whole  information  infrastructure  by  including: 
systems,  standards,  resources,  etc.  in  its  repository  definition.  DIRS  does  this  by 
modeling  information  asset  subtypes  and  the  entities  needed  to  manage  them. 

The  DIRS  Conceptual  Data  Standardization  Data  Model  View  at  the  meta 
metadata  level  includes  the  entities/concepts  of  group-attribute  and  dorived-data- 
attribute.  Jeff  would  like  our  help  in  better  defining/expanding  these.  He  would 
like  a  validation  session  for  review  of  the  complex  data  part  of  this  model.  He 
would  like  to  get  our  input  incorporated  into  a  proposal  package  that  he  wants  to 
submit  to  CIM  within  the  next  two  months. 

My  notes  included  a  recommendation  for  associating  data  class  with  a  base  type 
where  class  would  include  BLOBS,  icons,  etc. 

Jeff  said  there  is  a  question  about  cost  justification  of  a  data  standards  program. 
The  issue  being  the  cost  of  IRDS  data  and  the  move  to  a  central  logical  repository. 
He  gave  an  example  of  a  Motorola  repository  that  tracks  everything. 

We  will  try  to  set  up  another  meeting  possibly  in  early  April  to  go  over  the  DIRS 
model.  (I  really  need  some  help  in  better  understanding  it — I  don’t  know  about 
the  rest  of  you.) 

Duane  Hufford:  Report  on  DoD  Data  Standardization  and  Data  Reuse  Guidance 
for  Complex  Data  Elements  (draft) 

Duane  works  for  American  Management  Systems  and  has  been  doing  this  work 
for  CIM  through  Phil  Cykana.  This  writeup  will  contain  his  definitions.  His 
paper  is  available  through  RAND  on  request  and  his  briefing  charts  and  executive 
summary  are  in  Appendix  C. 

Definitions  of  complex  data: 

Embedded  or  inherited  information  contained  within  the  data  element 
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From  “Complex  Data  and  the  DoD  Data  Administration  Program”:  any 
structure  which  requires  order,  any  data  structure  which  may  be  of  variable 
length,  or  any  data  structures  which  require  a  pointer. 

Duane  identifies  four  types  of  complex  data: 

Composite:  data  elements  that  embed  intelligence  about  multiple  concepts  in 
their  names,  definition,  and  domains. 

Derived:  data  elements  representing  concepts  computed,  aggregated, 
transformed,  or  inferred  from  the  values  of  one  or  more  other  data  elements. 

Data  steam:  Ordered  bits  or  characters  formatted  to  represent  information  in 
a  variety  of  forms. 

Assembly:  data  entities  comprising  instances  of  data  which  relate  to  other 
instances  of  data  within  the  same  entity. 

Duane  then  gave  examples  of  each  of  these  and  a  way  to  represent  them  in  an 
IDEF1X  model.  He  has  asked  for  feedback  from  the  CDTF  as  to  what  is  not 
understandable  or  for  comments  and  recommendations. 

Jack  Sheehan:  Hard-Wired  Data  Hierarchies:  Hie  Tyranny  of  End-Use  Specific 
Representations 

Jack  described  three  heresies:  (1)  the  real  world  of  combat  is  not  2-D,  (2)  hardwire 
hierarchy  is  reuse  hard-kill,  and  (3)  data  complexity  is  not  an  intrinsic  property  of 
a  “data  element”.  RDBMS  is  composed  of  2-D  relational  tables.  The  challenge  is  to 
capture  multidimensional  nature  of  problems  and  make  the  projection  onto  the 
engine  of  choice.  One  maps  into  2-D  for  efficiency,  elegance,  and  reuse.  When 
one  addresses  his  heresies  1  and  2,  you  get  a  solution  to  complexity  for  free. 
Representation  of  data  as  complex  is  the  consequence  of  point  of  view.  Complexity 
is  not  an  intrinsic  feature.  He  discussed  discovering  these  ideas  when  he  was 
collecting  data  on  a  sonar  tow  array  system. 

Jack  Teller:  DMA  Data  Modeling  Project  for  MC&G  Standardization 
(A  summary  of  the  briefing  Jack  gave  at  the  I/DB  can  be  found  in  the  I/DB 
section.) 

The  aims  of  the  DMA  pilot  project  in  data  modeling  were  to  develop  a  cadre  with 
modeling  and  data  standardization  skills  and  to  develop  models  compatible  with 
the  Digital  Geographic  Information  Exchange  Standard  (DIGEST)  Feature 
Attribute  Coding  Catalog  (FACC).  They  developed  a  data  model  identifying  75 
potential  standard  data  elements  and  submitted  an  initial  package  of  10  data 
elements.  The  modeling  was  done  from  the  MC&G  perspective  and  did  not  extend 
to  individual  features  and  attributes.  Since  other  DoD  organizations  have  uses  for 
the  same  objects,  they  have  proposed  a  project  to  expand  the  perspective  from 
MC&G  DMA  expertise  to  include  DoD-wide  participation.  There  are  lots  of  users 
of  their  data  because  users  need  DMA  data  to  carry  out  their  missions.  However, 
it  is  hard  to  find  real  “owners”  of  MC&G  data  outside  of  DMA,  most  are  just 
providers. 

DIGEST  is  a  four  volume  standard  document  that  is  the  exchange  standard  for  all 
data  produced  by  DMA.  There  was  a  question  about  commercial  vendors  using 
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DMA  standards:  several  have  converted  DMA  data  into  their  own  formats.  DMA 
and  USGS  are  working  together  on  a  Federal  Data  Transfer  Standard  (FDTS). 

We  could  work  with  DMA  by  furnishing  M&S  participation  in  the  MC&G  model 
development.  This  should  be  a  high  priority  for  the  CDTF  since  DMSO  has 
recognized  a  need  for  data  standards  for  environmental  data. 


Discussion: 

Metrics:  we  need  to  collect  metrics  about  the  cost  and  benefits  of  developing 
standards  for  complex  data. 

This  list  titled  "metrics”  was  in  my  notes 
Number  of  change  requests 
Use  of  data  model 
How  many  affected 
What  are  the  issues 
Data  sharing  objectives 

Volunteers  for  additional  pilot  studies  in  complex  data  modeling  are  CENTCOM 
and  UTSS.  CENTCOM  will  be  using  JDBE  help  in  doing  data  modeling. 

6.4  SUBGROUP  ORGANIZATION 

The  Complex  Data  Task  Force  identified  three  subgroups: 

Categorization  of  Complex  Data  Subgroup  will  start  with  several  recent 
categorization  attempts  including  those  offered  in  Duane  Hufford’s  paper  and  the 
DMA  data  modeling  effort  and  try  to  feed  input  back  to  Jeff  Wolfe’s  DIRS  project. 

Members  are 

Len  Seligman  (MITRE)  co-chair 
Peter  Valentine  (Army/JDBE)  co-chair 
Jim  Augins  (consultant  to  ARMS) 

Carl  Carden  (ISA) 

Mike  Frame  (IDA) 

Dan  Hogg  (J8) 

Duane  Hufford 
Iris  Kameny  (RAND) 

Roy  Scrudder  (Army/JDBE) 

(JefT  Wolfe  (DISA/CIM) 

Pilot  studies  in  Complex  Data  will  be  done  by  UTSS,  CCTT,  CENTCOM,  DIS,  and 
DMA  data  modeling.  Chien  Huo  will  coordinate  and  JDBE  will  support. 

Taxonomy/Indexes  Subgroup  (a  subject  area  that  is  needed  by  the  Repository 
subgroup  and  the  database  and  M&S  directories  as  well):  task  is  to  develop 
indexes  to  be  used  for  accessing  information  about  models  and  simulations  and 
databases  in  DMSO  directories  as  well  as  in  reuse  libraries.  Will  try  to  build  off 
any  available  Component  indexes.  This  is  an  important  subject  for  M&S  projects 
such  as  CCTT  and  UTSS  as  well  as  non-M&S  efforts. 
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Members  are 
Dan  Hogg  (JS)  co-chair 
Iris  Kameny  (RAND)  co-chair 
Mike  Hopkins  (CENTCOM) 

Chien  Huo  (DISA/JIEO/CFS) 

Peter  Valentine  (Army/JDBE) 

Rep  from  University  of  Central  Florida  (DIS)? 

DIA?? 

??  Question  marks  indicate  a  desire  to  get  participation  from  these  organizations 
&5  FUTURE  MEETINGS 

April  6-7,  Categorization  Subgroup  meeting  at  IDA  to  get  initial  consensus  on 
complex  data  for  input  to  Jeff  Wolfe’s  DIRS  data  model. 
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logical  design.  Data  reduction  and  transformation  techniques 
should  be  addressed. 
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verification  and  validation  tests  described  in  the  profile  have  been 
stringently  carried  out. 
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added  authoritaive  sources  up  to  use  in  the  model. 
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the  priorities?  Is  there  a  need  for  selected  attributes  at  high  degrees  of  granularity  (e.g., 
attribute  level  for  some  attributes)  and  other  attributes  only  at  a  more  generalized  level, 
even  though  it  would  be  possible  to  provide  them  at  the  instance  level. 
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even  though  it  would  be  possible  to  provide  them  at  the  instance  level. 
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DEFENSE  STANDARDS  INFRASTRUCTURE 

TASK  FORCE  TEAM 
(SIT) 


BRIEFING  TO 


DMSO  INFORMATION/DATABASE  TASK 

GROUP 


FEBRUARY  16,  1994 


BY 
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BRIEFING  OVERVIEW 


o  BACKGROUND 
o  ITF  MISSION 
o  SIT  PURPOSE 
o  SIT  VISION 
o  SIT  MEMBERSHIP  PROFILE 
o  REPRESENTATIVE  IS SUES /SHORTFALLS 
o  SOME  SIT  RECOMMENDATIONS  TO  DMSO 
o  SOME  CURRENT  SIT  EFFORTS 
o  SIT  PRODUCTS 
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BACKGROUND 


o  TEN  INFRASTRUCTURE  TASK  FORCE  (ITF) 

TEAMS  WERE  CHARTERED  B7  THE  DEFENSE 
MODELING  AND  SIMULATION  OFFICE  (DMSO)  IN 
THE  SPRING  OF  1993: 

-  ARCHITECTURE 

-  BEHAVIORAL  REPRESENTATION  (AUTOMATED 
FORCES) 

-  C3I  -  MODELING  AND  SIMULATION  (M&S) 
INTERFACES 

-  DISTRIBUTED  INTERACTIVE  SIMULATION 
(DIS)  TESTBEDS 

-  INFORMATION  CLEARING  HOUSE  FOR  M&S 

-  INSTRUMENTATION 

-  NETWORKS 

-  SECURITY 

-  STANDARDS 

-  VERIFICATION,  VALIDATION,  AND 
ACCREDITATION  (W&A) 
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ITF  MISSION 


IDENTIFY  UNADDRESSED  INFRASTRUCTURE 
NEEDS  THAT  CUT  ACROSS  M&S  COMMUNITY 
("CITY  PLANNER'S"  PERSPECTIVE). 


IDENTIFY  SHORTFALLS/OPPORTUNITIES  IN 
EACH  INFRASTRUCTURE  AREA. 


RECOMMEND  PRODUCTS/ PROCESSES/PROPOSALS 
TO  MEET  SHORTFALLS. 
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SIT  PURPOSE 


o  PROVIDE  A  KEY  FOCAL  POINT  FOR 

GUIDANCE/LEADERSHIP  IN  M&S  STANDARDS/ 
STANDARDS -RELATED  MATTERS  TO: 

-  DMSO;  AND 

-  THE  BROADER  M&S  COMMUNITY. 


o  BUILD  CONSENSUS  AND  PRO-ACTIVELY  FOSTER 
COST  REDUCTIONS  THROUGH,  FOR  EXAMPLE: 

-  DEFENSE  CONVERSION  AND  DUAL  USE; 

-  MIGRATION  TO  A  VENDOR-NEUTRAL,  OPEN- 
SYSTEMS  ENVIRONMENT  (OSE) /OPEN- 
SYSTEMS  INTERCONNECTION  (OSI) ; 

AND 
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SIT  PURPOSE  (CONT'D) 


-  PROMOTING  THE  CULTURAL  CHANGE  TO 

INTERACTIVE,  DISTRIBUTED  SIMULATIONS 
AND  SYNTHETIC  ENVIRONMENTS. 


o  PUBLISH  PERIODIC  ASSESSMENTS  AND 
STUDIES . 


o  EVOLVE  A  "NATIONAL  PLANNER'S"  POINT  OF 
VIEW  (POV)  FROM  A  "CITY  PLANNER'S"  POV. 


6 


„V*Vv  .'3 


136 


SIT  VISION 


"TO  FACILITATE  THE  IDENTIFICATION, 
ESTABLISHMENT,  ACCEPTANCE,  AND  IMPLE¬ 
MENTATION  OF  STANDARDS,  PROTOCOLS,  AND 
OTHER  APPROPRIATE  MECHANISMS  TO  PROMOTE 
EFFICIENT  AND  EFFECTIVE  INTEROPERABILITY , 

■n 

OPEN  SYSTEMS,  AND  THE  REUSABILITY  OF 
HARDWARE,  SOFTWARE,  AND  DATA  FOR  AP¬ 
PLICATIONS  OF  M&S.  THESE  STANDARDS, 
PROTOCOLS,  AND  OTHER  MECHANISMS  WILL  BE 
CONSISTENT  WITH  AND  BUILD  UPON  CURRENT 
NATIONAL,  FEDERAL,  DoD-WIDE,  AND,  WHERE 
PRACTICAL,  INTERNATIONAL  STANDARDS." 
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SIT  MEMBERSHIP  PROFILE 


o  ACADEMIA 
,*  o  DEFENSE  AGENCIES: 

-  CENTRAL  IMAGERY  OFFICE 

-  DEFENSE  EVALUATION  SUPPORT  ACTIVITY 

-  DEFENSE  INFORMATION  SYSTEMS  AGENCY 

-  DEFENSE  MAPPING  AGENCY 

-  DEFENSE  MODELING  AND  SIMULATION 
OFFICE 

o  DEPARTMENT  OF  COMMERCE* 
o  DEPARTMENT  OF  DEFENSE 
o  DEPARTMENT  OF  ENERGY 
o  DEPARTMENT  OF  TRANSPORTATION* 
o  FEDERAL  EMERGENCY  MANAGEMENT 
ADMINISTRATION* 

o  FEDERALLY-FUNDED  R&D  CENTERS 
o  INTELLIGENCE  AGENCIES* 

O  JOINT  STAFF* 

o  MANUFACTURING  ASSOCIATIONS* 
o  MEDICAL  COMMUNITY* 
o  NATIONAL  AERONAUTICS  AND  SPACE 
ADMINISTRATION* 
o  PROFESSIONAL  ASSOCIATIONS* 
o  SERVICES 

o  U.S.  AIR  FORCE  PROJECT  2851 


*  IN  PROGRESS  OR  UNDER  CONSIDERATION. 
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REPRESENTATIVE  ISSUES/ 
SHORTFALLS* 


o  AVAILABILITY  OF  STANDARD  PROCESSES  AND 
MODELS  FOR  "COMPLEX"  DATA  AND  "OBJECTS". 

o  LACK  OF  SOFTWARE  REUSE  AND  REPOSITORY 
ACCESS . 


o  UNCOORDINATED  STANDARDS  DEVELOPMENT/USE 
WITHIN  AND  BETWEEN  DOD  AND  FEDERAL 
COMPONENTS . 


*  SEE  SIT  REPORT  01-94  FOR  COMPLETE 
LISTING/DETAILS . 
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REPRESENTATIVE  IS SUES /SHORTFALLS 

(CONT ' D) 


o  MOST  M&S  DOCUMENTATION  NONSTANDARD/ 
INFORMAL/NON-EXISTENT . 


o  EXISTING/EMERGING  STANDARDIZATION  LAGS 
BEHIND  TIME-LINE  NFQS  OF  M&S  COMMUNITY. 


o  PROLIFERATION  OF  NONSTANDARD/NON- INTER¬ 
OPERABLE  M&S  INFORMATION  SYSTEMS  (ISs) 
ACROSS  DOD  AND  FEDERAL  COMPONENTS. 
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SOME  SIT  RECOMMENDATIONS  TO 

DMSO* 


*'o  MSS  STANDARDS  COORDINATION: 


-  INVESTIGATE  LONER-COST  ALTERNATIVES 
TO  STANDARDIZE  MSS  DATA  TYPES/MODELS 
WITH  POTENTIAL  FOR  SHORT-TERM 
CONSENSUS  AND  PAYOFF; 


-  IDENTIFY/REDUCE/ELIMINATE  NON¬ 
STANDARD,  REDUNDANT,  AND  UNRECOGNIZED 
DATA/OBJECT  ACTIVITIES; 


-  FORMALLY  ADOPT  A  STANDARDS  FRAMEWORK 
(E.G.,  THE  TAFIM) ;  AND 


*  SEE  SIT  REPORT  01-94  FOR  COMPLETE 
LISTING/DETAILS . 
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SOME  SIT  RECOMMENDATIONS  TO  DMSO 

(CONT !D) 


-  ENSURE  THAT  DOD  INTERESTS  ARE 
ADEQUATELY  REPRESENTED  IN  ALL 
APPROPRIATE  NONGOVERNMENT  STANDARDS 
BODIES . 


o  M&S  STANDARDS  COMMUNICATIONS: 


-  PROVIDE  AN  AUTOMATED,  EXPERT  SYSTEM 
TO  GENERATE  HARDWARE  AND  SOFTWARE 
STANDARDS/STANDARDIZATION  PROFILES 
FOR  PROGRAM  MANAGERS;  AND 


-  COUNTER  HETEROGENEOUS  IS  PROLIFERA¬ 
TION  BY  AGGRESSIVELY  PROMOTING 
SEAMLESS  INTEROPERABILITY  ("ONE  CALL 
REACHES  ALL")  . 
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SOME  CURRENT  SIT  EFFORTS 


o  CROSS  MEMBERSHIP  WITH  OTHER  ACTIVE  ITF 
TEAMS. 


o  A  VISIONARY,  HIGH-LEVEL  ROAD  MAP  FOR  MSS 
STANDARDS/STANDARDIZATION . 

o  REVIEW  OF  STANDARDS/STANDARDIZATION 
ACTIVITIES/ ISSUES  INVOLVING  DMSO 
PROJECTS  FUNDED  IN  FY  1994. 


o  DRAFT  STANDARDS /STANDARDIZATION  LANGUAGE 
FOR  DMSO ' S  FY  1994/1995  INFRASTRUCTURE 
RFPs . 


13 
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SOME  CURRENT  SIT  EFFORTS 

(CONT 1 D) 


o  FUNCTIONS/FORM  OF  THE  SIT  INTERACTIVE 
BULLETIN  BOARD: 


-  OBJECTIVES : 

1.  SUPPORT  SIT  ACTIVITIES/PROCES¬ 
SES/PRODUCTS  ; 

2.  PROVIDE  M&S  COMMUNITY  SERVICES 
SUCH  AS: 

A.  CONTINUALLY-UPDATED  INFOR¬ 
MATION/GUIDANCE  ; 

B.  Q&A  ACCESS  TO  THE  COLLECTIVE 
EXPERTISE  OF  SIT  MEMBERS;  AND 

C.  AN  INFORMAL  M&S  STANDARDS 
FORUM. 


-  CURRENTLY  RESIDES  IN  THE  DMSO  IS. 
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SIT  PRODUCTS 

o  SIT  CHARTER* 

o  SIT  REPORT  01-94* 

o  SIT  MEETING  MINUTES* 

o  DRAFT  ROAD  MAP  FOR  M&S  STANDARDS /STAN 
DARD I ZATION 

*  ACCESSIBLE  THROUGH  THE  DMSO  IS. 
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Simulation  Data  and  Its  Management 
MORS  Mini-Symposium 


TRADOC  Analysis  Center 
ninq  and  Doctrine  Command 


16-18  November  1993 
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-Prioritize  standardization  effort  (Use  importance/priority 
of  individual  models  and  simulations  as  a  guide) 


Distributed  Interactive  Simulation  (DIS) 

"Data  Standards" 
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Interactive 


Data  Element  Standards 


INTERACTIVE 


-More  Efficiently 
-  Stronger  V&V 
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Standards  have  a  life 
cycle 


DATA  STANDARDS 
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Data  Standards 
Current  Efforts 
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Extended  Air  Defense  Test  Bed 
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TECNET:  EVOLUTION,  CAPABILITY,  AND  RESEARCH  AND  DEVELOPMENT  INITIATIVES 


George  F.  Hurlburt 

Naval  Air  Warfare  Center  Aircraft  Division 
Patuxent  River,  Maryland  20670-5304 


ABSTRACT 

The  Test  and  Evaluation  Community  Network 
(TECNET)  stands  on  the  leading  edge  of  Defense  weapons 
systems  Test  and  Evaluation  (T&E).  It  provides  information  of 
immediate  value  to  those  who  plan,  provision,  support, 
conduct  and  evaluate  the  results  of  developmental  and 
operational  tests  within  the  Department  of  Defense  (DoD). 
Operating  at  both  the  unclassified  and  System  High  SECRET 
levels,  TECNET  supports  information  vital  to  the  tester,  those 
who  support  test  facilities  and  those  who  commission  tests. 
TECNET  has  evolved  over  the  past  10  years  to  its  present 
capability.  It  now  supports  over  3,500  users  from  within  all 
the  armed  services.  It  contains  significant  data  bases, 
information  resources  for  the  tester  and  a  number  of  specialized 
electronic  information  services  including  electronic  mail, 
bulletin  boards,  facsimile,  and  file  transfer  capabilities.  A  full 
partner  in  the  Defense  Data  Network  and  the  Internet, 
TECNET  is  also  accessible  via  the  Federal 
Telecommunications  System  for  the  Year  2000  (FTS-2000) 
dial-up  service.  TECNET  is  not  static.  Its  development  is  user 
driven.  Its  focus  on  the  future  embraces  concepts  such  as 
advanced  user  interfaces,  groupware,  technology  transfer 
information  support,  and  Multilevel  Secure  (MLS) 
capabilities.  This  paper  traces  the  evolution  of  TECNET, 
defines  TECNET  as  it  exists  today,  and  highlights  where 
TECNET  must  go  in  the  future. 

The  TECNET  exists  to  support  both  developmental  and 
operational  T&E  communities  within  DoD.  Further,  and 
importantly.  TECNET  also  supports  T&E  customers  in  the 
larger  DoD  Acquisition  community.  TECNET  has  matured 
over  the  past  10  years  to  become  a  recognized  T&*i 
information  resource  for  DoD.  TECNET  continues  to  evolve 
with  modem  information  technology.  This  paper  describes 
TECNETs  evolution,  describes  its  current  capability,  and 
defines  its  future  direction  to  support  its  T&E  information 
mission. 

TECNET  was  initiated  in  1983  under  a  DoD  contract 
with  Clemson  University  to  determine  how  the  several  Joint 
Test  Forces  (JTF)  could  better  cooperate  with  one  another.  The 
proposed  solution  brought  the  concept  of  electronic  mail  to  the 
JTF.  This  recommendation  took  hold  in  an  era  when  such  a 
concept  was  still  considered  radical.  Electronic  mail  was  very 
much  in  the  province  of  computer  specialists.  It  awaited 
introduction  of  the  communicating  personal  computer.  Initial 
JTF  support  was  provided  by  a  subcontracted  commercial 
electronic  mail  vendor.  As  the  personal  computer  became  an 
acceptable  DoD  tool,  TECNET  began  to  slowly  extend  beyond 
the  JTF.  Other  test  organizations  began  to  see  benefit  in 
electronic  information  exchange.  TECNET  entered  a  dramatic 
expansion  phase  in  1986  as  the  armed  services  began  to 
seriously  embrace  the  electronic  mail  services  of  Clcmson's 
commercial  vendor.  Unfortunately,  the  price  of  the  commercial 
service  skyrocketed  as  the  business  volume  increased 


dramatically  with  use.  In  late  1986,  the  Office  of  the  Secretary 
of  Defense  (OSD)  called  for  a  critical  review  of  this  and  other 
costly  initiatives  to  facilitate  T&E  by  electronic  means.  The 
Naval  Air  Test  Center  (NAVAIRTESTCEN)  at  Patuxent 
River,  Maryland,  was  selected  and  funded  to  conduct  a  critical 
study  from  the  perspective  of  a  field  activity. 

The  NAVAIRTESTCEN  study  established  a  T&E 
framework  that  became  a  part  of  the  Defense  Systems 
Management  College  (DSMC)  T&E  curriculum.  In  a 
companion  technical  report,  NAVAIRTESTCEN  recommended 
that  all  existing  OSD  automation  initiatives  be  reduced  or 
scrapped.  The  report  made  one  exception  for  the  existing 
electronic  mail  capability  for  the  entire  DoD  T&E  community 
known  as  TECNET.  The  study  recommended  that  this 
fledgling  electronic  mail  capability  be  developed  and  moved  in- 
house  to  one  of  the  Major  Range  and  Test  Facility  Base 
(MRTFB)  activities  to  achieve  both  control  and  economy.  It 
further  stipulated  that  funding  for  Research  and  Development 
(R&D)  should  come  from  OSD  only  so  long  as  the  armed 
services  were  willing  to  provide  funds  for  Operation  and 
Maintenance  (O&M).  This  idea  predated  the  OSD  Central  Test 
and  Evaluation  Investment  Program  (CTEIP)  which  operates 
under  a  similar  principle.  In  1987,  after  appropriate 
coordination  among  the  services,  OSD  sponsored  the  creation 
of  a  TECNET  Steering  Commiuee  made  up  of  formally 
designated  service  representatives.  From  that  date,  all  TECNET 
O&M  funding  came  from  the  services  and  all  R&D  support 
came  from  OSD  under  Steering  Committee  recommendation. 
The  TECNET  Steering  Committee  was  subsequently  chartered 
under  the  Joint  Commander’s  Group  (JCG)  for  T&E,  which 
emerged  in  1989  from  the  services  in  response  to  growing 
high  level  involvement  in  T&E  investment  matters. 

In  1989,  a  Government  owned  version  of  TECNET 
software  became  operational  at  Clemson  University.  It  ran  on 
a  computer  acquired  for  the  cost  of  its  move  from  a  terminated 
JTF  program.  The  subcontract  vendor  was  retained  for 
communication  access  purposes  only.  The  costly  commercial 
electronic  mail  component  of  the  commercial  service  had 
become  unnecessary.  To  facilitate  a  smooth  transition  from 
Clemson  University,  TECNET  temporarily  operated  from  a 
backup  sister  computer  acquired  from  the  same  JTF  program. 
This  support  operation  ran  at  the  Aberdeen  Proving  Ground  for 
the  first  quarter  of  Fiscal  year  1990.  The  primary  TECNET 
computer  was  moved  to  NAVAIRTESTCEN  during  this 
backup  period.  There,  it  became  fully  operational  under  full 
Government  control  in  early  1990.  The  system  was 
subsequently  upgraded  in  1991  and  again  in  1993  to  take 
advantage  of  reduced  system  ownership  costs  and  increased 
demand  for  added  capability.  Through  a  scries  of  fully 
competitive  contract  solicitations,  Clemson  University  has 
retained  the  primary  R&D  role  for  TECNET.  The  DoD 
mandated  Defense  Data  Network  (DDN)  became  TECNETs 
preferred  method  of  access.  After  an  intermediate  competitive 
contract,  the  commercial  access  vendor  was  subsequently 
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replaced  by  FTS-2000  under  waiver  to  overcome  known  DDN 
limitations.  In  the  meantime,  TECNET  worked  with  DDN  to 
overcome  certain  of  these  service  limitations.  TECNET s  1990 
point  paper  influenced  DDN  to  increase  nation-wide  dial-up 
speeds  for  remote  users. 

Over  the  years,  TECNET  has  evolved  from  a  pure 
electronic  mail  capability  to  a  mature  repository  for 
information  of  immediate  value  to  the  entire  DoD  T&E 
community.  TECNET  played  a  major  role  in  support  of  the 
developmental  named  Unmanned  Aerial  Vehicle  (UAV) 
program  and  the  still  evolving  EA-6B  program  during 
operation  Desert  Storm  in  early  1992.  TECNET  was 
reportedly  instrumental  in  saving  lives  during  this  brief  war. 
TECNET  also  became  an  indispensable  tool  for  the 
Multiservice  Test  Investment  Review  Committee  (MSTIRC), 
the  T&E  Project  Reliance,  and  the  subsequent  T&E  Reliance 
Investment  Board  (TERIB).  TECNET  now  supports  over 
3,500  users  from  over  450  T&E  related  organizations. 
TECNET  use  is  strong  among  the  Army,  Navy.  Air  Force, 
Marine  Corps  and  numerous  Defense  Agencies.  Over  50  DoD 
acquisition  programs  are  represented  among  the  220  plus 
TECNET  Bulletin  Boards.  Other  TECNET  Bulletin  Boards 
support  current  news  and  an  array  of  timely  subjects  dealing 
with  T&E  matters.  T&E  related  directives,  instructions, 
guidelines,  instructional  course  offerings,  software  T&E  facts, 
environmental  and  service  specific  texts  appear  in  the 
TECNET  menus.  Global  Positioning  System  and  Radar 
calibration  Satellite  operations  are  chronicled  on  TECNET. 
TECNET  remains  one  of  the  few  DDN  computers  to  fully 
integrate  facsimile  capabilities  with  electronic  mail.  Most 
importantly,  TECNET  houses  the  DoD  T&E  Assets  Data 
Base. 

This  data  base  defines  Government  and  private  T&E 
assets  valued  over  one-  million  dollars.  It  contains  over  4,000 
plus  records  extending  through  DoD,  other  Government, 
industry  and  foreign  T&E  holdings.  The  existence  of  this  data 
base  established  for  the  General  Accounting  Office  that  DoD 
had  control  over  investments  through  knowledge  of  what  was 
available  within  DoD.  It  supported  the  establishment  of  the 
CTEIP  and  became  instrumental  in  supporting  MSTIRC, 
T&E  Reliance  and  the  TERIB.  It  also  gave  rise  to  the  second 
strong  arm  of  TECNET,  the  classified  version  of  TECNET. 

In  response  to  Operations  Security  concerns  over  the 
existence  of  the  T&E  Assets  Data  Base  in  early  1989, 
TECNET  became  deeply  involved  with  the  security  and 
protection  of  the  information  it  held.  Initial  extraordinary 
efforts  were  undertaken  to  enhance  the  security  of  the 
unclassified  version  of  TECNET.  These  provisions  have  been 
regularly  reenforced  and  further  augmented  with  solid  operating 
procedures.  The  TECNET  unclassified  system  is  certified  at  the 
C-2  level  of  trust  and  improvements  continue.  TECNET  also 
accepted  the  long-term  challenge  to  field  a  classified  system.  In 
1991,  an  accredited  System  High  SECRET  version  of 
TECNET  became  operational  at  the  C-2  level  of  trust  in  an 
appropriately  secured  area  of  the  Aberdeen  Proving  Ground. 
Using  the  same  familiar  TECNET  software  as  augmented  for 
required  classified  markings,  the  secure  version  of  TECNET 
was  formally  accredited  by  the  Arm"  in  1991.  Using  the 
former  JTF  computer,  last  employed  in  the  1989  transition 


from  Clemson,  the  secure  version  of  TECNET  became 
accessible  only  via  STU-IH  or  DoD's  SECRET  level  Defense 
Secure  Network  Number  One.  As  anticipated,  use  of  the 
TECNET  secure  system  has  grown  only  slowly  since  it  was 
fielded.  In  1993,  this  system  will  be  upgraded  to  a  more 
flexible  and  less  'costly  to  maintain  secure  architecture.  The 
new  secure  TECNET  system  will  also  soon  contain 
substantive  information  of  real  value  to  the  T&E  community. 
Plans  are  now  laid  to  field  a  compendium  of  data  bases 
involving  Electronic  Countermeasures,  Electronic  Warfare 
threats,  and  DoD  threat  simulators.  These  substantive 
improvements  will  begin  to  show  realistic  payback  in  terms  of 
secure  TECNET  utilization. 

At  the  same  time,  the  three  leading  DoD  data  bases  that 
contain  information  concerning  test  assets  and  facilities, 
including  the  DoD  T&E  Assets  Data  Base,  are  also  being 
effectively  combined  under  the  TECNET  roof.  Operating  under 
a  common  cursor  driven  user  capability,  these  data  bases  are  to 
be  housed  on  both  the  secure  and  unclassified  versions  of 
TECNET.  Accessed  individually  or  in  combined  fashion,  they 
will  contain  appropriately  classified  information  for  the  sites  at 
which  they  reside.  Thereafter,  a  common  data  base  made  up  of 
all  available  T&E  asset  information  will  be  developed  as  a 
single  DoD  standards  compliant  T&E  resource  data  base 
designed  to  operate  either  on  a  stand  alone  PC  data  base  or  on 
TECNET.  This  combined  data  base  capability  was  made 
possible  by  a  TECNET  sponsored  effort  through  the  Range 
Commander's  Council  (RCC)  starting  in  1990  to  create  a 
Common  Data  Dictionary  involving  T&E  resources.  The 
RCC  Common  Data  Dictionary  Group,  chaired  under  the 
Naval  Air  Warfare  Center  Aircraft  Division  (formerly 
NAVAIRTESTCEN),  has  considered  all  known  data  bases 
involving  T&E  resource  information.  The  data  dictionary  is 
currently  modeled  using  a  DoD  compliant  data  modeling  tool 
known  as  the  ICAM  Definition  tool.  The  creation  of  the 
combined  data  base  will  be  under  agreements  among  the 
services  independently  engineered  by  TECNET.  The  designated 
Program  Manager  for  this  capability,  however,  will  not  be 
drawn  from  within  TECNET.  Rather,  TECNET  supports  the 
concept  of  data  base  management  under  appropriately 
designated  subject  matter  experts.  TECNET  shall  only  serve  as 
the  conduit  to  deliver  the  informational  products  so  derived  to 
appropriate  consumers.  When  the  resultant  data  base  is  folded 
into  the  secure  TECNET  system,  the  DoD  T&E  community 
will  have  truly  arrived  in  the  electronic  age.  For  the  first  time, 
a  current,  classified  electronic  resource  will  exist  which 
permits  effective  test  and  test  investment  planning  throughout 
DoD.  At  that  time,  use  of  the  secure  TECNET  computer  is 
expected  to  skyrocket. 

Figure  1,  graphically  defines  the  TECNET  configuration 
for  the  near  term  as  described  above. 

In  the  meantime,  while  like  systems  tended  to  seek 
increasing  budgets  in  1993,  TECNET  announced  a  20% 
reduction  over  its  initial  1994  budget  Through  consolidation, 
rightsizing,  and  reexamination  of  work  flows,  TECNET  can 
take  advantage  of  the  dramatic  cost  reductions  made  possible 
through  the  rapidly  evolving  computer  industry  and  concerted 
internal  controls.  This  move  was  taken  only  after 
development  of  a  detailed  TECNET  economic  and  sensitivity 
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analysis  capability.  This  capability  serves  as  the  foundation  of 
a  complete  TECNET  business  case.  The  analysis  demonstrates 
that  TECNET  O&M  realizes  great  savings  as  compared  to 
alternative  methods,  delivers  more  than  comparable 
Government  systems,  and  costs  less  than  a  similar,  but  far  less 
custom,  commercial  services.  At  the  same  time  as  reducing 
O&M  expense.  TECNET  plans  to  greatly  expand  its  services 
to  keep  pace  with  demand.  The  TECNET  R&D  program 
continues  to  pay  cost  effective  dividends. 

TECNET  R&D  centers  on  three  critical  areas:  enhanced 
user  capabilities,  assisted  access  to  heterogeneous  data  whether 
structured  or  not,  and  a  MLS  capability.  This  research  is  vital, 
ongoing,  and  presses  the  state  of  the  an  in  network  capability. 

TECNET’s  users  guide  its  development.  User 
complaints,  gripes,  comments,  and  suggestions  from  a  variety 
of  sources  are  all  carefully  recorded  and  tracked.  The  resulting 
data  base  yields  periodic  Pareto  charts  that  point  toward 
statistically  significant  and  user  desired  system  characteristics. 
The  Pareto  chan,  together  with  industry  trend  assessments, 
strongly  influence  the  direction  of  TECNET  development.  All 
emergent  capabilities  in  TECNET  progress  from  Alpha  testing 
to  Beta  testing  and  finally  to  production.  Likewise,  as  new 
capabilities  enter  into  production,  logging  and  statistical 
process  control  techniques  help  track  detailed  system 
utilization  trends.  Thus,  TECNET  is  a  closely  monitored 
laboratory  where  new  capabilities  are  always  candidates  for 
further  improvement.  A  number  of  new  capabilities  are 
coming  to  the  forefront  in  1993. 

TECNET  users  have  long  desired  an  online  conference 
capability.  Such  a  moderated  capability  will  migrate  from  a 
carefully  controlled  Alpha  test  environment  to  active  Beta 
testing  by  summer's  end  in  1993. 

The  long  established  TECNET  main  menu  has  recently 
received  criticism  as  being  far  too  obtuse.  Many  feel  it  aims  at 
computer  function  as  opposed  to  true  T&E  support,  thus 
hiding  many  important  T&E  features.  In  August  1993, 
TECNET  plans  to  unveil  a  new  menu  system  designed  to 
permit  direct  navigation  to  valued  T&E  information.  This  new 
menu  will  also  support  direct  entry  of  desired  capabilities  based 
on  keyword  selection.  At  the  same  time,  a  new  user  mode 
based  on  an  interactive  cursor  driven  activity  will  enter  into 
Beta  test.  Critical  user  feedback  will  be  sought  on  these 
proposed  features  in  an  August  1993  user's  Forum.  The  earlier 
Beta  test  user  mode,  a  version  of  a  risk  free  menu  called 
"novice  mode,"  will  be  introduced  into  production  prior  to  Beta 
test  of  these  new  features. 

With  the  forthcoming  cursor  mode,  TECNET  will 
support  five  selectable  user  interfaces  designed  to  suit 
individual  tastes:  a  novice  mode,  a  menu  mode,  a  command 
mode,  a  cursor  driven  mode,  and  an  unprompted  expert  mode. 
With  the  advent  of  X-windows  and  PC  based  point  and  click 
interfaces  characterized  by  PC  windows,  Windows  NT,  and  the 
Macintosh,  TECNET  faces  yet  another  new  interface 
challenge.  While  retaining  the  five  character  based  modes, 
TECNET  must  now  also  operate  in  these  advanced  and  highly 
standardized  graphical  environments.  A  major  rewrite  of  the 
underlying  TECNET  software  will  make  these  capabilities 


available  far  before  DDN  and  other  DoD  protocols  will  be  able 
to  support  them  with  the  requisite  data  rates.  TECNET  will 
respond  by  increasing  dial-up  rates  to  greater  than  the  current 
9600  baud  capability. 

The  concept  of  "groupware"  for  decision  documentation 
and  support  represents  another  advanced  Field  with  great 
potential.  TECNET  will  soon  introduce  rudimentary  tools  for 
"different  time,  different  place"  moderated  brainstorming 
among  defined  interest  groups.  A  companion  "rack  and  stack" 
type  of  tool  will  permit  designated  users  to  "vote"  on  an  array 
of  defined  concepts.  This  voting  capability  serves  as  a  means 
for  remote  users  to  rank  options  either  selected  during  the 
brainstorming  phase  or  as  presented  by  a  moderator.  TECNET 
intends  to  field  such  geographically  independent  decision 
support  tools  to  conduct  its  own  Steering  Committee  business 
more  effectively  and  economically.  In  so  doing,  the  emergent 
capability  will  begin  to  take  shape  for  general  use.  The 
planned  return  on  the  investment  is  reduced  travel  and, 
hopefully  increased  small  group  efficiency  in  cases  where  the 
group  is  distributed. 

Where  possible,  TECNET  plans  to  link  to  remote  hosts 
supporting  needed  information.  Rather  than  attempting  to 
house  this  information  locally,  TECNET  has  chosen  to  take 
advantage  of  what  already  exists.  In  1993,  TECNET  made  such 
a  vital  linkage  with  the  DoD  Environmental  community's 
electronic  bulletin  board  capability.  Similar  cost  effective 
linkages  are  planned  in  the  coming  months.  Increasingly 
sophisticated  access  and  data  transfer  techniques  will  emerge. 

TECNET  is  also  investing  in  future  information 
handling  technology  aimed  at  access  to  heterogeneous 
information  scattered  throughout  the  world.  Such  investment 
may  well  prove  significant  for  DoD.  The  shift  from  fully 
fielding  mature  technology  to  developing  production  ready 
weapons  systems  profoundly  affects  DoD  acquisition  methods. 
The  related  concepts  of  technology  transition  and  insertion 
becomes  far  more  meaningful.  Access  to  relevant  technology 
information,  fueled  by  fast  emerging  scientific  and  technical 
information,  becomes  critical  in  an  environment  characterized 
by  rapid  scientific  advancement  and  punctuated  by  latent 
production  capability.  As  field  warfighter  requirements 
continue  to  appear  electronically,  the  affect  on  modern 
warfighting  capability  will  be  dramatic.  Acquisition  based 
information  systems  must  be  sufficiently  responsive  to  meet 
this  rapidly  evolving  information  mandate.  In  the  interim, 
DoD  continues  to  stress  the  importance  of  developing  tightly 
coupled  information  systems  under  Integrated  Computer  Aided 
Software  Engineering  methodologies.  While  such  data  driven 
transaction  oriented  systems  are  essential  to  the  orderly  conduct 
of  DoD's  business,  technology  based  information  will  become 
far  more  elusive.  It  lives  and  breathes  in  the  Internet.  Those 
who  need  to  pursue  such  data  must  be  provided  the  necessary 
tools.  These  tools  extend  far  beyond  tightly  coupled  data  bases. 

TECNET  decided  to  first  attack  this  issue  head-on  and 
right  at  home.  TECNET  now  houses  significant  amounts  of 
relevant  T&E  information  in  many  forms  and  formats. 
Unfortunately,  there  is  no  search  capability  to  seek  all  the 
information  available  on  any  given  topic  within  the  TECNET 
information  base.  Thus,  TECNET  proposes  to  introduce  a 
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"Hypersearch"  capability  in  1993.  The  initial  capability  will 
provide  a  user  with  all  relevant  information  pertaining  to 
searches  as  specifically  defined  by  user  request.  This  capability 
will  launch  a  new  phase  in  TECNETs  continuing  evolution. 

Hypersearch  initiates  a  larger  quest.  The  need  to  access 
relevant  information  in  the  broader  context  of  the  Internet 
becomes  more  crucial  by  the  day.  Existing  tools  such  as  the 
World  Wide  Webb,  WAIS,  and  a  number  of  enterprising 
"Gophers"  support  such  initial  search  capabilities.  TECNET  is 
in  the  initial  phases  of  experimentation  with  these  tools. 
While  promising,  they  can  yield  limited  results  and  consume 
costly  resources  in  their  execution.  Directed  searches  must  be 
better  focused.  They  must  know  how  to  target  high  payoff 
sources  and  perform  searches  against  the  resources  therein. 
They  must  yield  maximum  results  at  lowest  expense. 
Advanced  search  capabilities  must  be  able  to  target  highly 
structured  data  bases  and  free  text  with  equal  ease.  They  must 
be  able  to  interpret  complex  data  structures,  such  as  models 
and  reusable  software.  They  must  glean  intelligence  from 
pictorial  material.  They  must  be  able  to  interpret  user  requests 
in  a  contextual  framework.  In  short,  they  must  be  smart. 

TECNET,  together  with  a  number  of  leading  DoD  agents 
for  technology  transition  and  information  transfer,  will  soon 
participate  in  a  series  of  planned  experiments  based  on  such  an 
intelligent  search  capability.  The  TECNET  component  of  the 
emerging  capability  will  be  nested  in  the  TECNET  T&E 
resource  data  bases.  Directed  intelligent  search  capabilities  will 
be  employed  to  better  isolate  relevant  test  capabilities  based  on 
rather  "fuzzy"  user  requirement  statements.  The  results  will  be 
based  on  weighted  criteri'".  Likewise,  TECNET  will  draw  upon 
other  identified  and  shares  network  based  resources  among  the 
other  experimental  participants  to  fully  support  answers  to 
technology  based  questions.  While  oriented  to  corporate 
learning,  this  series  of  experiments  will  give  rise  to  new 
capabilities  not  yet  imagined.  Unfortunately,  as  these 
experiments  proceed,  the  issue  of  security  will  become 
paramount.  The  technology  data  derived  will  undoubtedly 
become  too  sensitive  to  treat  in  an  open  and  shared 
environment.  Thus,  security  considerations,  particularly  the 
role  of  MLS,  cannot  be  ignored. 

The  existing  classified  TECNET  system  serves  as  a 
precursor  to  the  desired  MLS  TECNET  capability.  Such 
capability  obviously  depends  on  what  hardware  and  software 
the  National  Security  Agency  (NSA)  approves.  The  hardware 
and  software  components  of  MLS  are  important,  but  as  pans 
of  a  system,  they  are  not  the  total  solution.  A  system  also 
comprises  policy,  procedure,  and  labor.  In  the  absence  of 
overarching  national  MLS  policy,  procedure  must  be 
developed.  Likewise,  labor  requirements  to  operate  a  true  MLS 
system  must  be  fully  defined  and  documented  if  adequate 
network  resourcing  is  to  occur.  These  components  must  be 
wrapped  into  a  tightly  coupled,  well  regulated  "system"  before 
an  intelligent  accreditation  decision  can  be  rendered.  TECNET 
has  engaged  in  a  funded  1993  experiment  aimed  at  empirical 
documentation  of  the  policy,  procedure,  and  labor  components 
involved  in  fielding  a  nationally  networked  MLS  capability. 
Involving  Air  Force,  Army,  and  Navy  participants  at 
designated  service  sites  and  working  closely  with  NSA, 
TECNET  is  carefully  documenting  its  findings. 


Documentation  is  taking  shape  in  the  form  of  NSA-based 
experimental  templates  for  MLS  systems.  The  1993  MLS 
experimentation  and  documentation  will  give  rise  to  1994 
work  with  emerging  hardware  and  software  systems  rated  at  a 
level  of  trust  to  permit  a  true  MLS  capability  on  the  scale 
envisioned  for  TECNET.  While  much  remains  to  be 
accomplished,  TECNET  is  making  steady  progress  in  defining 
methods  by  which  information  may  be  managed  at  varying 
levels  of  depth  and  corresponding  classification.  The  plan  is  to 
migrate  TECNET  from  the  C-2  level  of  trust  to  the  B-2  level 
of  trust  extending  from  unclassified  through  secret  coresident 
on  all  TECNET  machines  and  accessible  by  appropriately 
trusted  users  and  hosts.  Such  management  is  essential  if  DoD 
is  to  preserve  the  national  security  in  an  increasingly  insecure 
world  where  information  has  a  measurable  value. 

Figure  2  graphically  defines  the  TECNET  configuration 
for  the  long-term  as  described  above. 
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1994  holds  many  changes 
Read  about  them  in  this 
issue 
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New  talents  on  board;  old 
friends  move  on 
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New  TECNET  menu 
system  operational 


The  new  TECNET  Menu  System  was 
introduced  in  late  December  after  sev¬ 
eral  months  of  beta  testing.  This  system 
takes  advantage  of  several  behind  the 
scenes  improvements  which  we  made 
to  the  TECNET  software  over  the  sum¬ 
mer. 

These  changes  permit  us  to  mix  and 
match  such  things  as  bulletin  boards, 
file  repositories,  FAX  repositories,  data 
bases  and  menus  under  a  common  TEC¬ 
NET  menu  selection.  Now,  rather  than 
segregate  like  data  by  its  structure  as 
has  been  our  practice,  we  can  now  link 
data  by  related  subjects. 

Titus,  if  a  given  subject  area  includes 
a  data  base,  a  bulletin  board  and  a  re¬ 
pository,  ail  three  of  these  selections 
can  now  appeal  under  a  common  menu. 
Thus,  to  find  information  related  to  a 
given  subject,  it  is  no  longer  an  adven¬ 
ture  in  menu  searching. 

We  have  tried  to  make  the  new  TEC¬ 
NET  Menu  structure  relate  to  the  busi- 


New  Production  features 

So  that  you  have  an  idea  of  how 
much  disk  space  your  account  occu¬ 
pies,  an  announcement  of  disk  space 
txrcpied  appears  at  each  login.  If  you 
have  a  large  amount  of  space  in  use. 
wc  encourage  you  lo  purge  unused  or 
out  of  date  files.  A  temporary  patch 
has  also  been  moved  which  hastens  ac¬ 
cess  to  the  File  repositories.  We  arc 
working  on  even  faster  access  to  these 
repositories,  but  that  may  take  a  bit  of 
time  to  implement. 


ness  of  Defense  Test  and  Evaluation. 
Of  course,  the  new  menu  structure  is 
different  Thus,  it  will  require  a  bit  of 
experimentation  before  you  get  used  to 
it’s  layout  The  exploded  menu  struc¬ 
ture  is  revealed  in  a  companion  mes¬ 
sage  found  in  the  "tecnet  Bulletin 
Board.  You  may  wish  to  review  this 
message. 


Change  in  9 Bcc ' 

Due  to  a  new  version  of  the 
mail  system  that  has  been  rolled 
to  production,  the  Bcc  field  has 
been  slightly  modified.  Individu¬ 
als  receiving  a  blind  carbon  copy 
will  have  "Blind  Carbon  Copy" 
displayed  in  the  Bcc  field  as  op¬ 
posed  to  their  user  id  which  is 
how  it  worked  before  ihe  new  ver¬ 
sion  was  rolled.  Likewise,  the 
sender  will  not  be  able  to  verify 
who  he  has  Bec’d  by  referring  to 
the  message  in  his  ’out'  box. 

The  message  in  the  out  box  will 
simply  display  "Blind  Carbon 
Copy"  in  the  Bcc  field. 

More  changes  coming, 
stay  tuned! 

1 993  gave  us  many  new  changes 
on  TECNET.  It’s  a  safe  bet  ilia! 
many  more  are  going  to  come  your 
way.  Many  new  types  of  informa¬ 
tion  too.  Stay  tuned! 
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New  Facsimile 


(FAX)  Capab 


by  C.  Reid  Harmon 
TECNET Development  Staff 


TECNET  is  proud  to  present  a  ma¬ 
jor  expansion  of  its  FAX  capabili¬ 
ties.  The  FAX  problems  recently 
associated  with  the  production  sys¬ 
tem  of  TECNET  were  related  to 
preparations  to  introduce  these  new 
FAX  capabilities.  The  FAX  System 
is  now  once  again  fully  operational. 
The  enhancements  include  full  com¬ 
patibility  between  FAX  and  file  re¬ 
positories.  the  ability  to 
automatically  upload  FAXes  to  a 
new  personal  FAX  repository  and 
greatly  enhanced  FAX  addressing 
capabilities.  The  following  outline 
details  the  specific  enhancements: 


L  The  Sew  FilefFAX  Repository 
I  System 

I  Formerly  the  differences  between 
the  File  Repository  System  and  the 
FAX  Repository  System  were  sig¬ 
nificant.  despite  most  operations  of 
the  two  systems  are  really  the  same. 

:  To  remove  the  differences,  we  have 
rewritten  the  file  repository  system, 
it  now  handles  both  files  and 
FAXes.  More  importantly,  both  the 
,  repositories  now  have  the  same  look 
j  and  feet. 

1  A.  Repository  location 

The  file  repository  is  located  un- 
j  der  the  "File  Transfer/Reposilory 
,  Systems"  option  from  the  main 
TECNET  menu. 


DoubleVision  -  what’s  that? 


One  may  ask  if  it's  possible  for 
two  things  to  occupy  the  same 
space  at  the  same  time.  On  TEC¬ 
NET,  it  is  not  only  possible,  but 
happens  more  times  than  it  should. 

If  you  have  to  log  off  TECNET 
in  a  hurry,  take  extra 
second  to  enter  the 
letter  ’’E’’  to  Exit  at 
any  point  during 
your  session.  If  you 
don't.  TECNET 
keeps  your  account 
active  and  on-line  for 
about  15  minutes. 

This  time  is  actually  tied 
to  the  timer  that  keeps 
track  whether  or  not  there  is 
any  activity  on  your  account. 

If  you  don't  touch  your  keyboard 
for  that  time.  TECNET  will  log 
you  off.  What’s  worse,  if  you  log 
back  in  r vichin  a  15-minute  win¬ 
dow  after  your  first  improper  exit, 
TECNET  will  raise  a  red  flag.  The 
system  now  believes  there  are  two 
people  using  your  account  at  the 


same  time. 

Once  DoubleVision  is  detected 
on  your  account,  the  system  gener¬ 
ates  an  attention  message  and 
sends  it  to  your  mailbox.  Logging 
out  properly  will  do  three  things: 
Avoid  nasty  notes  from  TEC¬ 
NET.  reduce  on-line  charges  for 
that  period  and  reduce  sys¬ 
tem  congestion. 
DoubleVision  notes  will 
make  you  aware  of  oth¬ 
ers  who  are  using  your 
account  (with  or  without 
your  permission).  It  also 
tips  you  off  as  to  whether 
your  password  has  been 
compromised. 

If  you  are  aware  of  another 
individual  utilizing  your  account, 
wc  strongly  urge  you  to  register 
them  for  their  own.  If  yon  are  not 
wc  ask  that  you  please  contact  TE- 
CADMIN  and  Change  your  pass¬ 
word. 


ilities 

The  FAX  repository  is  located  on 
the 'FAX  Repository  Services’  op- 
I  tion  under  the  'FAX  Services’  op- 
j  tion  from  the  main  TECNET  menu. 

|  B.  Changes  in  the  file  repository  system 

There  is  one  real  change  in  die 
file  repository  system:  It  may  now 
|  contain  FAX,  text  and  binary  files. 

•  If  you  select  a  FAX  on  a  File  Re¬ 
pository  menu,  you  will  not  be  able 
to  display  its  contents,  but  you  are 
now  able  to  FAX  or  forward  it  to  a 
FAX  or  another  repository. 

By  request,  the  Repository  system 
menu  is  now  a  single-column  menu, 
rather  than  a  double-column  menu, 
and  includes  the  file  size  and  file 
type. 

C.  Differences  Between  File  and 
FAX  Repositories 

The  behavior  of  file  and  FAX  re¬ 
positories  is  based  on  the  nature  of 
files  and  FAXes  themselves.  There¬ 
fore,  it’s  important  to  understand 
what  the  differences  are  between 
each.  The  classification  file  refers  to 
any  item  stored  on  the  system.  It 
may  be  one  of  three  ’types’: 

•  Text:  Text  (or  ASCII)  files 
contain  only  letters,  numbers, 
punctuation  marks,  and  other 
symbols  you  can  find  on  a  key¬ 
board.  In  short,  text  is  read¬ 
able  material,  typed  in  by 
hand. 

•  FAX:  A  FAX  document  is  a 
graphics  format;  it  describes 
where  on  pages  there  should 
he  black  spaces  and  printed 
spaces,  which,  as  a  whole,  wc 
perceive  as  symbols,  draw¬ 
ings.  and  even  writing.  A 
FAX,  then,  is  a  type  of  file,  at 
least  when  it  is  stored  on  TEC¬ 
NET.  This  distinction  is  impor¬ 
tant  as  we  usually  do  not  con¬ 
sider  the  paper  itself  someone 
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has  FAXed  to/from  be  a  com¬ 
puter  file.  In  this  case,  the 
standard  Group  III  FAX  has 
been  encoded  as  a  computer 
file  for  it's  life  on  TECNET. 


•  Binary:  This  is  a  catch-all  cate¬ 
gory  for  every  other  type  of; 
file.  Binarv  tiles  can  be  com¬ 
pressed  data,  graphics,  or  DOS 
executable. 


You  now  have  your 
own  personal  FAX 
repository  In  which  you 
may  keep  FAX 
documents,  and 
forward  them  or  FAX 
them  out,  just  like  you 

may  with  a  public 
repository. 


Firfr  repository  has  an  associated 
file  type  File  repositories  contain 
every  kind  of  Pie;  FAX  repositories 
contain  onlv  those  files  which  can 
be  FAXed.’  inis  includes  FaXcs,  of 
course,  but  also  text  files  which  can 
be  converted  to  FAX  files. 

There  is  one  additional  difference 
between  the  two  repository  types, 
uploads  are  restricted  to  file  reposi¬ 
tories. 

E.  Differences  Betw  een  Action  Menus 


Once  you  select  a  file  in  a  reposi¬ 
tory.  the  system  determines  its  type, 
and  then  presents  you  with  an  Ac¬ 
tion  Menu  —  a  list  of  options 
which  you  may  perform  on  that  file. 
Not  all  actions  apply  to  all  file 
types,  so  the  menu  is  limited  to  only 
what  you  may  do  with  that  particu¬ 
lar  file.  The  following  is  a  list  of  re¬ 
strictions  on  the  Action  Menu 
selections: 

•  Download:  Not  available  to 
FAXes.  since  as  files  they  arc 
stored  with  header  informa¬ 
tion  which  PC  FAX  packages 
will  not  recognize. 

•  Display  Contents:  Available 
only  to  text  files,  since  binary 
file’s  can  be  of  many  formats. 


and  FAXes  can  only  be  dis¬ 
played  on  a  graphics  screen. 

•  FAX  Out:  Restricted  to  ‘fax- 
able’  files,  which  are  text  files 
and  FAXes. 

•  Forward  to  Another  Reposi¬ 
tory:  All  types  of  files  may  be 
forwarded,  but  only  Taxable 
files  may  be  forwarded  to  a 
FAX  Repository. 

All  other  Action  Menu  options 
are  available  to  all  file  types. 

//.  The  Personal  FAX  Repository  and 
automatic  FAX  uploads 

You  now  have  your  own  personal 
FAX  repository  in  which  you  may 
keep  FAX  documents,  and  forward 
them  or  FAX  them  out,  |ust  like  you 
may  with  a  public  repository. 

The  major  difference  is  the  ability 
to  FAX  a  document  directly  into 
i  your  own  private  FAX  repository , 

|  The  first  step  in  FAXing  yourself  a 
|  document  is  to  use  a  TECNET  pro- 
I  vided  bar  coded  FAX  cover  sheet 
which  identifies  you  personally. 

To  have  a  personalized  bar  coded 
l  cover  sheet  sent  to  you,  or  to  a  an¬ 
other  individual  wishing  to  FAX 
you  something  via  TECNET.  select 
the  Generate  Fax  Cover  sheet  option 

on  the  FAX  Services  menu,  and  fill 
out  the  necessary  recipient  informa¬ 
tion  as  requested. 

Then  use  this  cover  sheet  on  top 
of  the  stack  of  document  pages  to  be 
I-AXed,  and  FAX  the  whole  works 
to  the  number  listed  at  the  bottom  of 
the  coversheet. 

Once  TECNET  receives  your 
FAX.  the  automatic-routing  system 
wilt  scan  the  bar  code  at  ihc  top.  de¬ 
termine  that  you  are  the  intended  re¬ 
cipient,  place  the  FAX  into  your 
repository,  and  send  you  an  elec¬ 
tronic  mail  message  that  you  have 
received  a  new  FAX. 

HI.  FAX  Distribution  lusts 

A.  FAX  Addrcsws 

On  the  new  FAX  Services  menu, 
there  is  a  ’Create  and  Maintain  box 
Address  Entries’  option.  With  it, 
you  may  create  FAX  addresses  (re¬ 
cipient  name,  office,  organization, 
voice  phone,  and  FAX  phone  intOf- 
mation)  1-AX  addrevses  are  distin¬ 
guished  by  other  kinds  of  addresses 
with  a  preceding  dollar  sign  (S). 

B.  Distribution  Lists 


Under  the  'Create  and  Maintain 
Fax  Address  Entries'  option  is  the 
'Mail  Distribution  List  Manipula¬ 
tion '  option,  which  allows  you  to 
create  and  edit  mail  distribution 
lists.  The  new  distribution  lists, 
used  by  both  the  mail  and  FAX  sys- 
I  terns,  allow  you  to  specif)'  recipients 
by  either  electronic  mail  (E-mail)  ad- 
!  dresses,  or  FAX  addresses.  For  ex¬ 
ample,  you  may  create  a  distribution 
list  called  ‘help’,  which  contains  the 
following: 

tecadmin.rekJ@tecnet5cs.clem- 
,  son.edu.Sjoe 


FAX  addresses  are 
distinguished  by  other 
kinds  of  addresses 
with  a  preceding  dollar 
sign  ($)  _ 


i  The  first  two  items  arc  both  E- 
mail  addresses,  but  the  last  item, 

!  ’Sjoe’ .  is  a  FAX  address  which  is 
recognized  as  a  FAX  address  by  the 
dollar  sign  ($). 

•  Mail  System  Treatment  of  Dit- 
tributlon  Lists.  If  you  mail  a 
message  to  #help.  your  private 
distribution  list,  recognized  as 
a  disiriouiion  Usi  by  ilic  lead¬ 
ing  pound  sign  (#).  the  mail 
system  will  send  an  E-mail 
message  to  tecadmin  and 
reid@tecnet5.cs. demson  cdu. 
but  will  FAX  a  message  to  the 
recipient  specified  by  Sjoe. 

This  is  helpful  for  including 
people  in  your  distribution 
lists  who  have  FAX  machines, 
but  no  E-mail  address. 

•  FAX  System  Treatment  of  Dis¬ 
tribution  Lists.  If  you  send  a 
FAX  ro  #hclp.  the  FAX  sys¬ 
tem.  being  unable  to  send  a 
FAX  via  E-  mail,  will  ignore 
the  E-mail  addresses  in  your 
distribution  list,  and  use  only 
the  FAX  addresses. 

•  FAX  Requests.  Since  distribu¬ 
tion  lists  arc  now  supported, 
there  have  been  some  changes 
lothe  interactive  FAX  Trans¬ 
mission  Kequest  system.  At 
the  'To'  prompt,  there  are  now 

Continued  next  pope 
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three  choices  with  which  you 
may  specify  recipient(s). 

1.  By  Name  and  FAX  Phone 
This  method  has  not  been 
changed.  You  may  enter  informa¬ 
tion  on  each  of  the  fields  to  specify 
a  recipient.  The  default  entry  is 
shown  in  square  brackets  ([]).  The 
’To'  field,  and  the  two  fields  speci¬ 
fying  the  FAX  phone  number  must 
be  filled  out. 

1  By  FAX  Address 
Instead  of  specifying  each  field,  at 
the  ‘To’  prompt  you  may  instead 
specify  a  FAX  address  (e.g.  Sjoe). 
and  the  fieJd  information  ,‘rom  the 
FAX  address  will  be  used  instead. 
This  is  a  great  time-saving  advan¬ 


tage  for  when  you  have  someone  to 
whom  you  regularly  send  FAXes. 

3.  By  Distribution  List 
In  specifying  a  distribution  list 
(e.g.  #help),  all  of  the  FAX  ad- 
.  dresses  are  displayed,  and  each  be¬ 
comes  a  recipient  This  is 
j  particularly  helpful  when  you  have 
j  a  group  of  people  to  whom  you  send 
FAXes. 

After  you  enter  this  information 
and  specify  one  or  more  recipients, 
you  will  encounter  a 'Add  Send 
Quit?  (Add]:1  prompt.  You  may  en- 
.  ter  an  ’S'  to  send  the  FAX  to  your 
list  of  recipients,  a  'Q'  to  quit  the  re¬ 
quest  and  not  send  the  FAX,  or  an 
:  ‘A*  (by  default),  which  will  take 
you  back  to  the  ’To’  prompt  and  al¬ 
low  you  specify  more  recipient(s). 

In  this  way.  you  do  not  have  to 
make  a  distribution  list  just  to  send 
a  FAX  to  more  than  one  person  at  a 
!  time.  If  you  have  a  FAX  that  you 


wish  to  send  to  Joe  and  Mike,  then 
you  may  enter  'Sjoe’  at  the  'To' 
prompt,  an  'A'  to  add  another  recipi¬ 
ent.  ’Smike’  at  the  next  'To'  prompt 
(if  you  have  created  a  FAX  address 
■  called  'mike',  that  is),  and  then  an 
;  ’S’  to  send  the  FAX. 
j  This  flexibility  should  greatly  en- 
hance  the  utility  of  the  TECNET 
1  FAX  system. 

TV.  Qusstinru 

TECADMIN,  (30 1  -826-750 1 ) 
stands  ready  to  assist  with  the  use  of 
|  These  new  TECNET  features. 

Please  direct  any  questions  or 
comments  about  the  new  Repository 
1  system  and  FAX  Distribution  List 
usage  to  the  ‘comments  or  the  ‘bug- 
box  bulletin  boards  as  appropriate 

C.  Reid  Harmon  Jr.  •  TECNET 
Development  Staff  reid@tec- 
net5.cs.clemson.edu. 
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December  breaks  new  record 


With  its  holidays,  December  is  tra¬ 
ditionally  slow  in  terms  of  TECNET 
utilization.  While  many  TECNET 
users  focus  on  family  and  friends  at 
month's  end.  TECNET  statistics 
tend  to  show  a  corresponding  de¬ 
cline. 

Despite  this  annual  trend.  TEC¬ 
NET  records  were  set  in  December 
for  the  number  of  unique  users  and 
the  total  number  of  registered  users. 

AM  WC  SMTP 
Directory  is 
now  online 

For  those  of  you  wishing  to  cor¬ 
respond  with  individuals  in  the 
Naval  Air  Warfare  Center 
(NAWC)  a  new  remote  connec¬ 
tion  to  the  on  line  NAWC  Simple 
Mail  Transfer  Protocol  (SMTP) 
is  available.  This  feature  permits 
a  search  bv  name  for  individuals 
in  the  NAWC  structure.  The  fea¬ 
ture  is  available  from  the  new  Ac¬ 
cess  Remote  Internet  Services 
Menu. 


The  total  numbers  of  accesses  and 
the  overall  connect  time,  while  not 
record  breaking.  Were  still  very  re¬ 
spectable  figures.  These  numbers 
placed  December  at  the  third  high¬ 
est  spot  and  well  above  many  pre¬ 
vious  months. 

Despite  expected  slowdown  at 
month's  end,  the  system  utilization 
was  significant  during  the  weeks  be¬ 
fore  the  holidays.  Thus,  the  seasonal 
dip  was  not  as  pronounced  as  in  past 
years. 

TECNET  had  little  in  the  way  of 
internal  problems  in  December, 
save  for  an  indiscrete  circuit  board 
which  decided  to  become  unseated 
late  on  December  27th.  This  board 
was  re-seated  that  evening  with  no 
further  problem.  Most  of  the  prob¬ 
lems  wc  observed  were  external  to 
our  environment.  In  early  Decem¬ 
ber,  wc  experienced  some  severe 

Rrobletns  with  our  Defense  Data 
letwork  (DDN)  circuit  which 
hacked  up  our  outgoing  mail  for  a 
little  over  a  day. 

Our  focus  on  this  external  ptob- 
Icm  helped  lead  to  its  timely  conclu¬ 
sion,  We  also  have  indications  that 
some  DDN  and  Internet  mail  is  not 
getting  to  us. 


While  we  are  tracing  these  re¬ 
ports,  they  tends  to  be  elusive  as 
they  arc  rooted  in  the  DDN  or  In¬ 
ternet  network  routing  infrastruc¬ 
tures.  If  you  know  of  traffic  not 
getting  to  us.  it  would  be  helpful  to 
tell  us  the  originating  host  computer 
from  which  the  traffic  was  sent.  We 
are  also  still  tracking  the  very  elu¬ 
sive  FTS-2000  performance  prob¬ 
lems  which  are  sporadically 
reported  to  us.  Again,  your  reports 
are  our  lifeline  to  better  serving  you 
as  you  access  TECNET. 


More  news  than  ever 
before 

In  case  you  haven't  noticed,  the 
‘news wire  and  ‘news  bulletin 
boards  should  keep  you  abreast  of 
just  about  anything  that  is  happen¬ 
ing  in  the  world  today. 

The  China,  Russia,  South  East 
Asia  and  Croatia  news  arc  only 
some  of  the  new  products  available. 

Now  there  is  no  reason  being 
kept  in  the  dark  when  things  are 
happening  ail  around  the  globe. 

Next  time  you  have  a  few  mo¬ 
ments,  stop  on  by  and  see  what’s 
going  on  in  the  world. 
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Technical  or  functional  disapproval:  returns 
data  element  to  materiel  developer  for  correction. 


Army  Data  Model  Integration 


Sequence  Influenced 
by  RCAS  and  SBIS 
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omplex,  Complicated,  Derived  Data 

-  Examples:  Images ,  multimedia,  assemblies  &  aggregations, 
performance  characteristics,  software,  documents ,  behavior, 
algorithms,  data  streams 

-  Becoming  important  to  ql[  information  systems 
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Data  Model 
for 

Modeling  and  Simulation 
Directory 

presented  by 

Roy  Scradder,  JDBE  Project 


•  Initial  project  started  as  an  update  of  SSDCs 
Analytical  Tool  Box 

•  DMSO  sponsored  project  to  develop  DoD 
standard  data  model  for  M&S  Directory 

•  JDBE  provided  review  and  consulting 

•  IDA  to  provide  implementation 


I 

I 
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Information  Sources 


•  MOSAIC  -  Army  Master  Model  and  Simulation 
Catalog 

•  J8  Catalog  of  Wargaming  and  Military 
Simulation  Models 

•  Navy  Model  and  Simulation  Catalog 

•  Navy  SMART  Program 

•  SSDC  Analytical  Tool  Box 

•  Center  for  Naval  Analysis  Survey 

V _ _ 


Activities 


•  Draft  data  model  developed  by  COLSA 

-  Entities  and  attributes  identified  and  defined 

-  Partial  specification  of  domain  information 

-  Preliminary  assignment  of  data  types 

-  Preliminary  design  of  user  interface 

•  Model  reviewed  by  DMSO,  SSDC,  AMSMO, 
DIA/MISIC,  SMART,  and  JDBE 

•  Model  updated  to  reflect  review  comments 
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Analyze 

Train 

Test 

Evaluate 

Design 

Support 

Construct 

Drive 


Architecture 

Environment 

Weather 

Nuclear 

Chemical 


Operations 


Weapon  Air  Global 

Fire  Unit  Space  National 

BN  and  Below  Ocean  Theater 

Corps  and  Div  Surface  Tactical 


Above  Corps  Subsurface  Individual 

Joint  Bottom *  * 

*  Ground 


Follow-on  Objectives 


•  Integrate  the  M&S  Directory  and  Data  Base 
Directory  Data  Models 

•  Complete  taxonomy  and  domain  information 

•  Add  DISA/QM>compliant  naming 

•  Submit  M&S  Directory  Data  Model  as  an 
extension  to  DoD  Data  Model 

•  Submit  candidate  standard  data  elements 

•  Develop  a  directory  of  M&S  and  data  bases. 
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DMSO  Model  &  Simulation  Directory 
Entity-level  Logical  Data  Model 
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Developed  by  COLSA  Corporation:  10  Jan  94 
Modified  by  JDBE:  10  Feb  94 
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DMSO  Model  l  Simulation  Directory 
FuUy  Attributed  Logical  Data  Modal 
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Legend 
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Developed  by  COLSA  Corporation:  10  Jan  94 
Modified  by  JOBE:  10  Feb  94 
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Hardware-T ype _ The  name  of  the  vendor  of  the  host  computer  system. _ 

Operating-System _ The  operating  system  version  that  this  computer  system  uses. 

Memory-Requirement  The  amount  of  random  access  memory  (RAM)  required  to  run 

_ this  model. 
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Level-OMnteraction  A  description  o ( the  level  of  human  interaction  used  by  the 

_ model. _ _ _ 

Required-Or-Optional  An  indicator  of  whether  human  interaction  is  required  or 

_  optional. 
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A  unique  identifier  of  an  input  used  by  the  model  used  to 
distinguish  between  possible  multiple  inputs  to  the  same 
model  version. 

A  description  of  this  input  data  requirement  for  this  model.  i 

A  description  of  the  format  required  for  the  input  data.  1 

A  unique  identifier  of  a  model  input  dataset.  1 

The  name  of  the  dataset.  1 

The  revision  date  of  the  dataset.  1 

The  security  classification  of  the  input  data  set.  ] 

A  system  generated  unique  identifier  to  distinguish  between 
multiple  input  development  aids  used  to  prepare  a  model 
input. 
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The  estimated  time  required  to  prepare  the  model  input  using 
this  input  development  aid. 

The  estimated  level  of  effort  required  to  prepare  the  model 
input  using  this  input  development  aid. 

A  word  or  phrase  that  identifies  a  level  modeled  for 
categorization  of  the  model  or  simulation. 

A  unique  identification  for  a  model.  I 

Complete  name  of  the  model.  1 

mo  auuuyin  ui  mu  iiiuuci.  | 

A  brief  description  of  the  model.  I 

The  dale  the  model  was  first  used.  1 

The  identifier  number  of  the  model  version  that  has  most  I 

recently  been  released. 

A  unique  identifier  used  to  differentiate  between  possible 
multiple  interactions  of  the  same  two  model  versions. 
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Modification-Id  A  unique  identifier  used  to  distinguish  between  possible 

_ multiple  modifications  planned  for  the  same  model. 
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A  description  of  the  planned  modification  of  the  model.  I 

The  projected  date  that  the  modification  will  be  completed 
and  released. 

Indicates  the  number  of  sides  that  can  be  represented  in 
competition  in  the  model. 

An  indication  of  whether  the  distribution  of  capabilities  to  | 

sides  in  the  conflict  are  asymmetric  or  symmetric.  I 

An  indicator  whether  the  sides  to  react  to  interactions  with 
opponents. 

A  unique  identifier  for  an  organization.  i 

The  name  of  the  organization.  i 

The  address  of  the  organization.  1 

A  unique  identifier  used  to  differentiate  between  possible 
multiple  responsibilities  performed  by  the  same  organization 
for  a  model  version. 

A  unique  function  performed  by  an  agency.  1 

'  A  unique  identifier  used  to  distinguish  between  possible 
multiple  outputs  from  the  same  model  version. 

The  type  of  output  of  the  model.  I 

A  description  of  this  type  of  output  from  the  model.  1 

The  security  classification  of  this  model  output.  f 

A  unique  identifier  used  to  distinguish  between  possible 
multiple  peripherals  of  the  same  computing  system. 

The  name  of  the  peripheral  device.  f 

The  type  of  peripheral  hardware.  1 

A  description  of  the  peripheral.  1 

A  unique  identifier  for  a  person.  | 

Modification-Description 

Projected-Completion-Date 

Number-Of-Sides 

Symmetry 

Reactive 

Organization-Id 

Organization-Name 

Address 

2 

♦ 

] 

5 

c 

s 

a 

l 

s 

* 

\ 

i 

\ 

* 

Function 

Output-Id 

Output-Type 

Output-Description 

Output-Security-Classification 

Peripheral-Id 

Peripheral-Name 

Peripheral-Type 

Peripheral-Description 

Person-Id 

I  MULTIPLE 

I  ORGANIZATION 

I  ORGANIZATION  .RESPONSIBILITY 

1  OUTPUT 

1  PERIPHERAL 

1  PERSON 

02/10/94 

J 


DMSO  Model  and  Simulation  Directory 
Logical  Data  Model 


Parameter-Description _ A  description  of  the  input  parameter. _ 

Parameter-Affect-On-Run-Time-  A  description  of  the  affect  on  run-time  contributed  by  this 
Description _  input  parameter. 
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catalogs  for  use  of  personnel  and  agencies  without  Internet  access 

Catalogs  Contain  Only  Descriptions  of  M&S  Programs,  Not  the 
Actual  Programs  or  Data 


1C  M&S  CATALOG 


350 


03 

3 

ts 

o> 


CO 

X 

* 

© 

O) 

© 


(0 

JD 

JD 

(0 

> 

o 

E 

© 

V. 

Si 

2 

o 


© 

c 

■  ■M 

o 

© 

E 

CO 

CO 

<0 

CO 

CO 


c 

© 


c 

o 

•  ■Mi 

n 

©  = 
W  CL 
© 
o 

o  - 

<  £ 

03  +-*■ 

s  g. 

3  o 
£  ~ 
■  a 

Q..S 

<  © 
+■* 

*  © 

>  TJ 

Si 

ffi  ® 

■o  E 
*  © 
©  2S 

o  < 

© 


o 

© 


© 

c 


c 

o 


© 

© 


© 

o> 

_o 

© 


© 

© 

© 

o 

o 

■D 

k. 

© 

© 

4-J 

TJ 

© 

C 

c 

© 

*■* 

© 

© 

O) 

_c 

o 

4-* 

3 

© 

4-» 

o 

© 

o 

4-» 

03 

© 

© 

•w 

JD 

E 

© 

© 

C 

E 

© 

© 

> 

4-* 

c 

a 

C 

3 

o 

o 

© 

E 

© 

E 

© 

o 

■o 

O 

© 

© 

3 

© 

o 

© 

c 

© 

© 

o> 

■■■ 

S3 

■© 

4-» 

O 

4-» 

c 

zz 

““ 

© 

o 

o 

LL 

© 

4-» 

© 

a 

© 

E 


© 

o 

© 

4-* 

© 


T3 

© 

4-> 

© 


© 


© 


Classified  portion  of  1C  M&S  catalog  will  contain  additional  fields 
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VV  &  A  has  to  start  from  “square  one 
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An  Analogy 
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Obviously,  M&S  is  more  complex 
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J-MASS  provides  toolset,  EXPERTS  provide  models 
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•  Support  for  Ada  and  C++  models 
-  Visual  programming  to  generate/modify  models 


How  was  J-MASS  Designed? 
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Providing  a  common  architecture  the  experts  can  use 
to  build  models  for  the  DoD  community 
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Current  Features  (Rel  2.0) 
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Demonstration  of  J-MASS/DIS  Interface  (Using  DIS  1.0  PDUs) 

-  Identified  J-MASS  areas  that  would  have  to  be  enhanced  to  better 
support  DIS  exercises 


J-MASS  Users/Beta  Sites 
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:  First  functional  version  (Rel  2.0)  just  now  available 
-->  To  date,  not  much  real  use  of  system 


J-MASS  Release  3.0  (Dec  94) 
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-  Backward  compatibility  with  Release 

-  Accompanied  by  a  “How  To”  Manual 


Beyond  Release  3.( 

(not  all-inclusive) 
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Ada  9X  (long  term) 

Better  C++  integration 
Additional  analysis  features 


Summary 
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Provides  the  strong  foundation  M&S  needs 
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DEPARTMENT  OF  THE  NAVY 

OFFICE  OF  THE  CHIEF  OF  NAVAL  OPERATIONS 
WASHINGTON.  DC  20350-2000 


IN  REAL*  REFER 


OPNAVINST  9410.6 
N65 

13  July  1993 


OPNAV  INSTRUCTION  9410.6 


TO 


From:  Chief  of  Naval  Operations 


Subj:  NAVAL  WARFARE  TACTICAL  DATABASE  (NWTDB)  REQUIREMENTS 
FOR  TACTICAL  NAVAL  WARFARE  SYSTEMS 


Ref: 


(a)  DOD  Directive  8320.1  of  26  Sep  91,  "DOD  Data 
Administration"  (NOTAL) 

(b)  DOD  Manual  8320.1-M-l  of  15  Jan  93,  "DOD  Data  Element 
Standardization  Procedures"  (NOTAL) 

(c)  DOD  Directive  4630.5  of  12  Nov  92,  "Compatibility, 
Interoperability  and  Integration  of  Tactical  Command, 
Control,  Communications  and  Intelligence  (C3I) 

Systems"  (NOTAL) 

(d)  OPNAVINST  9410.5,  "Database  and  Communication 
Standards  Interoperability  Requirements  for  Tactical 
Naval  Warfare  Systems"  (NOTAL) 

(e)  SECNAVINST  5400.15  of  5  Aug  91,  "Department  of  the 
Navy  Research,  Development,  and  Acquisition 
Responsibilities"  (NOTAL) 

(f)  SECNAVINST  5000. 2A  of  9  Dec  92,  "Implementation  of 
Defense  Acquisition  Management  Policies,  Procedures, 
Documentation,  and  Reports"  (NOTAL) 

(g)  OPNAVINST  5000. 42D  of  19  Apr  93,  "OPNAV  Role  and 
Responsibilities  in  the  Acquisition  Process"  (NOTAL) 

(h)  NWTDB  Management  Plan  of  Sep  92  (NOTAL) 

(i)  OPNAVINST  3430. 23B  of  12  Jun  92,  "Tactical  Electronic 
Warfare  Reprogrammable  Library  Support  Program"  (NOTAL) 

(j)  OPNAVINST  3140.54  of  3  Nov  86,  "Submission  of 
Oceanographic  and  Meteorological  Requirements"  (NOTAL) 

(k)  OPNAVINST  3140.55  of  5  Mar  87,  "Submission  of 
Requirements  for  Mapping,  Charting,  and  Geodesy  (MC&G) 
Products  and  Services"  (NOTAL) 


Enel:  (1)  Definitions 

(2)  NWTDB  Reference  Database  Production  Architecture 

(3)  Interim  NWDTB  User  Feedback/Requirements  Report 


1.  Purpose.  To  establish  responsibilities  and  procedures  for 
evolving  to  a  common  tactical  database  architecture  that  supports 
naval,  joint,  and  combined  operations.  Specifically,  to: 


0579LD0369070 
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OPNAVINST  9410.6 

13  JUL  893 

a.  Implement  Command,  Control,  Communications,  and 
Intelligence  (C3I)  data  administration  and  systems 
interoperability  requirements  in  accordance  with  references  (a) 
through  (c) ; 

b.  Provide  a  management  framework  for  Navy  to  resolve  data 
interoperability  issues  which  impact  tactical  naval  warfare; 

c.  Designate  Functional  Database  Managers  (FDBMs)  and  specify 
their  duties;  and 

d.  Reduce  long  term  naval  warfare  system  acquisition  costs  by 
evolving  to  a  joint  and  theater  compatible  information 
architecture  which  will  be  applied  to  both  the  requirements  and 
engineering  processes. 

2.  Supercession.  The  guidance  in  this  instruction  supersedes 
guidance  found  in  reference  (d)  regarding  NWTDB.  All  other 
provisions  of  reference  (d)  remain  in  effect  until  canceled  or 
superseded  by  other  means . 

3.  Scope/ AppI icabil itv .  This  policy  is  issued  in  accordance 
with,  and  in  amplification  of,  references  (e)  through  (g) .  It 
applies  to  all  organizations  acquiring  and  supporting  Tactical 
Naval  Warfare  Systems  (TNWSs)  and  associated  database  production, 
including  those  organizations  acquiring  systems  under  rapid 
prototyping  and  fleet  initiative  programs. 

4.  Definitions.  Terms  used  in  this  instruction  are  defined  in 
enclosure  (1) . 

5.  eagjsgrwnfl 

a.  Systems  involved  in  warfare  and  warfare  support  must  be 
able  to  exchange  data.  Incompatible  data  definitions,  naming 
conventions,  and  structures  make  this  difficult.  Program 
managers  are  forced  to  develop  and  maintain  unique  databases  with 
specialized  interface  design  specifications  to  other  systems 
because  data  standardization  efforts  have  been  fragmented, 
community  specific,  and  inadequate.  This  is  neither 
operationally  effective  nor  cost  efficient. 

b.  The  Department  of  Defense  Corporate  Information  Management 
(CIM)  effort  was  initiated  in  1990  to  reduce  acquisition  costs. 
CIM  is  chartered  to  develop  Department  of  Defense  process  models, 
data  models,  and  information  systems,  and  to  standardize  the 
computing  and  communications  infrastructure  of  DOD.  A  primary 
CIM  objective  is  to  develop  a  single  DOD  data  element  dictionary 
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to  improve  interoperability  among  systems  and  facilitate  data 
exchanges.  The  Defense  Information  Systems  Agency  (DISA)  is 
developing  the  Defense  Data  Repository  System  (DDRS)  to  support 
this  effort.  DOD  components  are  directed  to  participate  in  the 
process  as  described  in  references  (a)  and  (b) .  Per  reference 
(a),  applicable  Federal,  national,  and  international  data 
standards  are  preferred  over  unique  DOD  standards.  Thus,  where 
Navy  or  DOD  develops  unique  standards,  future  modifications  will 
be  necessary  to  evolve  to  higher-precedence  standards  once 
available.  NWTDB  provides  the  management  framework  for  achieving 
this  evolution  for  Navy  tactical  data  standards  once  approved 
joint  standards  are  available. 

c.  The  Joint  "C4I  for  the  Warrior"  and  Navy  "Copernicus" 
efforts  set  forth  concepts,  unifying  themes,  and  principles  for 
achieving  C4I  interoperability  that  is  global,  reliable,  secure, 
affordable,  and  responsive  to  warfare  operations.  Interoperable 
databases  and  data  standardization  are  essential  to  achieving  the 
common  systems  processing  required  to  support  these  objectives. 

d.  The  concept  for  achieving  tactical  data  interoperability 
is  contained  in  reference  (h) .  This  concept  includes  NWTDB 
reference  database  production  as  depicted  in  enclosure  (2),  as 
well  as  data  requirements  and  Navy  C3I  data  administration. 

6.  Policy 

a.  Reference  (a)  requires  that  information  be  treated  as  an 
asset  directly  accessible  throughout  an  organization .  Effective 
data  administration  provides  the  means  to  share  data,  control 
redundancy,  minimize  data  handling,  and  improve  data  integrity. 

b.  All  Navy  system  developers  and  database  producers  will 
transition  to  NWTDB  data  standards  and  structures  by  the  year 
2000.  At  present,  NWTDB  includes  only  a  minimum  baseline  of  data 
standards.  Additional  data  elements  or  data  sets  required  for 
tactical  naval  warfare  may  be  developed  by  or  in  coordination 
with  system  developers  as  candidate  DOD  standards.  This  includes 
the  data  elements  required  to  support  modeling  and  simulation,  as 
well  as  training.  Chief  of  Naval  Operations  (N6)  and  Office  of 
Naval  Intelligence  (ONI-73)  will  provide  management  support  to 
assist  developers  in  this  endeavor. 

c.  It  is  the  responsibility  of  system  sponsors  and  developers 
to  plan  and  budget  for  the  evolution  of  existing  systems  to 
approved  joint  and  Navy  standards.  Navy  C3I  baseline  data 
standards  will  be  derived  from  existing  data  element  formats  and 
definitions  by  Functional  Database  Managers  (FDBMs)  in 
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cooperation  with  system  developers.  These  formats,  in  turn,  will 
be  coordinated  with  joint  standards  managers  as  described  in 
reference  (b) .  In  the  long  term,  NWTDB  will  reduce  both  software 
development  and  maintenance  costs.  A  phased  integration  of 
functional  data  standards  using  budgeted  funds  through  normal 
configuration  management  is  less  expensive  than  proliferation  of 
unique  data  formats,  with  translators  for  each  new  application. 
System  milestone  reviews  shall  address  data  interoperability. 

d.  The  NWTDB  process  refocuses  existing  resources  to 

(1)  Identify  and  integrate  user  and  system  data 
requirements , 

(2)  Register  existing  Tactical  Naval  Warfare  System 
(TNWS)  data  elements  to  use  in  baseline  standards, 

(3)  Institute  and  manage  Navy-approved  C3I  data 
standards,  and  submit  these  as,  or  evolve  to,  joint  data 
standards , 

(4)  Implement  approved  standards  in  all  TNWSs,  and 

(5)  Provide  consistent,  authoritative  tactical  reference 

data. 

e.  NWTDB  policy  execution  does  not: 

(1)  Dictate  hardware  or  software  for  systems  use, 

(2)  Dictate  which  standard  data  elements  to  implement, 

(3)  Dictate  system  applications,  or 


(4)  Dictate  internal  system  data  handling. 


a.  Director  of  Space  and  Electronic  Warfare  (N6)  will: 


(1)  Act  as  the  Chief  of  Naval  Operations'  (CNO)  point  of 
contact  for  C3I  data  administration  and  information  technology 
issues.  Provide  overall  management  and  direction  for  NWTDB. 


(2)  Coordinate  and  submit  Navy  position  and  submit 
recommendations  to  DOD  agencies  regarding  integrated  C3I 
interoperability  standards.  Positions  will  be  submitted  via  the 
Navy  data  administrator  when  required  by  SECNAV  instruction. 
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(3)  Integrate  Navy  configuration  management  of  C3, 

Combat,  and  Intelligence  data  standards  (Database,  Message  Text 
Formats,  and  Tactical  Data  Information  Links) . 

(4)  Prepare  a  Configuration  Management  Plan  for  detailed 
instruction  on  submission  of  requirements  and  approval  process  of 
candidate  data  elements. 

(5)  Plan,  program,  and  budget  adequate  resources  to 
ensure  Navy  command  and  control  systems  implement  Joint  and  Navy 
C3I  data  standards. 

b.  Director  of  Naval  Intelligence  (N2)  will: 

(1)  Manage  for  the  CNO  the  submission  and  status  of 
Tactical  Naval  Warfare  Systems  intelligence  production 
requirements  to  Commanders  in  Chief  and  agencies. 

(2)  Support  N6  in  Navy  C3!  data  administration  and  data 
element  harmonization. 

(3)  Plan,  program,  and  budget  adequate  resources  to 
ensure  Navy  General  Defense  Intelligence  Program  and  Tactical 
Cryptologic  Program  systems  implement  Joint  and  Navy  c3I  data 
standards. 

c.  Oceanographer  of  the  Navy  (N096)  will: 

(1)  Manage  for  the  CNO  the  coordination  and  submission  of 
TNWS  mapping,  charting,  and  geodesy  requirements  to  the  Defense 
Mapping  Agency  (DMA) ;  and  meteorology,  oceanography,  and 
astrometry  requirements. 

(2)  Support  N6  in  Navy  C3I  data  administration  and  data 
element  standardization. 

(3)  Plan,  program,  and  budget  adequate  resources  to 
ensure  Navy  environmental  systems  implement  Joint  and  Navy  c3I 
data  standards. 

d.  Deputy  Chief  of  Naval  Operations  for  Resources,  Warfare 
Requirements,  and  Assessments  (N8)  will: 

(1)  Ensure  Navy  modeling  and  simulation  systems  use  NWTDB 
standards  and  structures. 
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(2)  Support  N6  in  Navy  C3I  data  administration  and  data 
element  standardization. 

(3)  Use  NWTDB  format  in  production  and  maintenance  of 
U.S.  Navy  weapons  systems,  and  for  platform  characteristics  and 
performance  data  to  meet  the  needs  of  wargaming  and 
implementation  on  TNWSs. 

e.  CNO  Resource  and  Program  Sponsors  will: 

(1)  Submit  existing  TNWS  data  element  formats  and 
definitions  to  the  Office  of  Naval  Intelligence  for  registration 
and  consolidation  into  candidate  DOD  standards . 

(2)  Ensure  new  or  upgraded  systems  use  NWTDB  standards 
and  structures,  and  that  existing  systems  transition  by  the  year 
2000,  unless  systems  have  been  specifically  given  exemptions  by 
N6. 


f.  System  Development  Managers  (Systems  Commands,  Program 
Executive  Officers,  and  Direct  Reporting*  Program  Managers)  will: 

(1)  Coordinate  the  implementation  of  NWTDB  in  TNWSs 
through  the  Force  Warfare  Systems  Engineering  Board. 

(2)  Prepare  implementation  plans  to  support  the 
requirements  of  this  instruction  within  their  commands . 

(3)  Designate  a  single  point  of  contact  for  external 
coordination  of  data  standardization  issues. 

(4)  Provide  existing  TNWS  data  element  definitions  and 
formats  to  ONI  for  registration  in  NWTDB. 

g.  Office  of  Naval  Intelligence  (ONI)  will: 

(1)  Act  as  the  NWTDB  Standards  and  Structure 
Administrator  for  CNO  (N6) . 

(2)  Register  TNWS  data  elements  in  the  NWTDB  Systems 
Information  Directory,  and  coordinate  preparation  of  candidate 
joint  standards  for  submission  to  the  DISA  Defense  Data 
Repository  System  (DDRS)  for  approval  as  joint  standard  data 
elements . 


(3)  Identify  conflicting,  redundant,  or  required 
production  of  data  and  recommend  solutions  to  CNO  (N6) . 
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(4)  Coordinate  data  set  design  and  dissemination  of  the 
NWTDB  Standards  and  Structures  Manual. 

(5)  Develop  and  manage  NWTDB  dissemination  procedures 
with  the  FDBMs,  including  maintenance  of  a  master  list  of  users 
and  holdings. 

(6)  Coordinate  the  NWTDB  configuration  management 
process,  to  include  review  of  submitted  data  elements  for 
technical  accuracy. 

h.  Navy  FDBMs  (listed  in  paragraph  7i  below)  will: 

(1)  Coordinate  NWTDB  data  set  structure  design  with  ONI, 
to  comply  with  reference  (b)  standards. 

(2)  Disseminate  data  in  accordance  with  NWTDB  data 
element  format  and  data  set  structures.  The  common  medium  for 
file  dissemination  between  database  producers  and  users  will  be 
American  Standards  Code  for  Information  Interchange  (ASCII) 
unless  all  parties  agree  upon  a  substitute  coding  format  which  is 
approved  by  ONI.  The  intent  is  to  evolve  to  a  single,  industry 
compatible,  dissemination  standard  which  permits  data  compression 
for  communication  transfer.  Enclosure  (2)  illustrates  the 
projected  standard  reference  database  production. 

(3)  Oversee  NWTDB  configuration  management  within  their 
functional  area  to  include  functional  review  of  submitted  data 
elements  to  ensure  they  meet  operational  requirements.  Produce 
applicable  portion  of  the  NWTDB  Standards  and  Structures  Manual 
in  coordination  with  ONI. 

i.  Navy  NWTDB  FDBMs  and  their  areas  of  concern  are  as 
follows: 

(1)  ONI  -  Characteristics  and  performance  (C&P)  data  of 
non-U. S.  equipment  and  merchant  ships, 

(2)  Commander,  Space  and  Naval  Warfare  Systems 
(COMSPAWARCOM)  -  Provide  U.S.  Navy  C&P  data  in  support  of 
modeling  and  simulation  and  TNWSs, 

(3)  Officer  in  Charge,  Electronic  Warfare  Operational 
Programming  Facility  (EWOPFAC)  -  Radar  parameters  data  (reference 
(i)  pertains), 

(4)  Commander,  Naval  Security  Group  (COMNAVSECGRU)  - 
Cryptologic  (i.e.,  communications  intelligence)  data,  and 
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(5)  Commander,  Naval  Oceanography  Command 
(COMNAVOCEANCOM)  -  Oceanography,  meteorology,  astrometry,  and 
mapping,  charting,  and  geodesy  (references  (j)  and  (k)  pertain). 

j.  Participating  non-Navy  NWTDB  FDBMs  are: 

(1)  Defense  Intelligence  Agency  -  Non-U. S.  installations, 
equipment,  and  order  of  battle  data. 

(2)  Atlantic  Intelligence  Command  (AIC) /Joint 
Intelligence  Center  Pacific  (JICPAC)  -  Theater  specific 
installation,  amphibious,  lines  of  communication  and  order  of 
battle. 


k.  Navy  Center  for  Tactical  Systems  Interoperability  (NCTSI) 
will: 


(1)  Review  proposed  changes  to  NWTDB  standards  and 
structures  for  impact  on  tactical  system  implementation  and 
interoperability  of  Tactical  Data  Information  Links  and  Message 
Text  Format  systems. 

(2)  Monitor  compliance  with  NWTDB  standards  in 
conjunction  with  C4I  systems  interoperability  testing  efforts. 

1.  Fleet  Commanders  in  Chief  will: 

(1)  Identify  data  standards,  structure,  fill,  or  transfer 
problems/requirements  to  appropriate  FDBM.  If  it  is  unclear 
which  FDBM  is  appropriate,  submit  requirements  to  ONI.  Enclosure 

(3)  may  be  used  for  submission  of  requirements  until  a  formal 
configuration  management  plan  is  published  or  electronic 
submission  becomes  available. 

(2)  Ensure  TNWSs  developed  under  rapid  prototyping  and 
fleet  initiative  programs  incorporate  NWTDB  standards.  Recommend 
to  appropriate  FDBM  the  producer  of  data  where  not  otherwise 
assigned. 

8.  procedures 

a.  Reference  (b)  and  the  proposed  DOD  manual  8320. l-M,  "Data 
Administration  Procedures",  describe  procedures  to  be  followed  in 
data  administration  and  data  element  standardization.  These 
procedures  are  fully  supported  and  adopted  by  the  NWTDB  process. 
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b.  A  configuration  management  plan  and  an  implementation 
plan  are  being  produced  by  OPNAV  (N6)  in  support  of  this 
instruction.  In  the  interim,  enclosure  (3)  may  be  used  to  submit 
requirements  to  FDBMs  or  ONI-73. 

9.  Report .  The  reporting  requirement  contained  in  enclosure  (3) 
is  assigned  symbol  OPNAV  9410-1  and  is  approved  for  three  years 
from  the  date  of  this  instruction. 
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DEPTKTTIONB 

Sources  of  definitions  are  listed  where  available. 

Application  Data  Element.  A  data  element  used  in  an  automated 
information  system.  (An  application  data  element  may,  or  may 
not,  be  a  standard  data  element.) 

Attribute.  A  property  or  characteristic  of  one  or  more  entities; 
for  example,  COLOR,  WEIGHT,  SEX.  Also,  a  property  inherent 
in  an  entity  or  associated  with  that  entity  for  database 
purposes.  (FIPS  Pub  11-3) 

Corporate  Information  Manage®  '  ^.t  { :JX) .  The  DOD  effort  to  apply 
computing,  telecommunicat  \s,  and  information  management 
capabilities  effectively  i*.  the  accomplishment  of  the 
Department  mission. 

Data.  A  representation  of  facts,  concepts,  or  instructions  in  a 
formalized  manner  suitable  for  communication,  interpretation, 
or  processing  by  humans  or  by  automatic  means.  (FIPS  Pub 
11-3) 

Data  Administration  (DAdm) .  That  function  of  the  organization 

which  oversees  the  management  of  data  across  all  functions  of 
the  organization,  and  is  responsible  for  central  information 
planning  and  control.  (NBS  Special  Pub  500-149) 

Data  Administrator  (DAd) .  A  person  or  group  that  ensure  the 

utility  of  data  used  within  an  organization  by  defining  data 
policies  and  standards,  planning  for  the  efficient  use  of 
data,  coordinating  data  structures  among  organizational 
components,  performing  logical  database  design,  and  defining 
data  security  procedures.  (NBS  Special  Pub  500-152) 

Data  Attribute.  A  characteristic  of  a  unit  of  data  such  as 

length,  value,  or  method  of  representation.  (FIPS  Pub  11-3) 

Data  Category.  All  data  sets  necessary  to  define  a  functional 
category,  e.g.,  sensors.  The  number  of  data  sets  per 
category  is  based  on  specific  data  file  record  capabilities. 

Data  Content.  What  goes  in  a  data  element  as  defined  by  the  data 
element  definitions  and  formats. 

Data  Dietionary.  A  specialized  type  of  database  containing 
metadata  that  is  managed  by  a  data  dictionary  system;  a 
repository  of  information  describing  the  characteristics  of 
data  used  to  design,  monitor,  document,  protect,  and  control 
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data  in  information  systems  and  databases;  and  application  of  a 
data  dictionary  system.  (FIPS  Special  Pub  500-152) 

Data  Element.  A  named  identifier  of  each  of  the  entities  and 
their  attributes  that  are  represented  in  a  database.  (FIPS 
Pub  11-3) 

Data  Element  standardization.  The  process  of  documenting, 
reviewing,  and  approving  unique  names,  definitions, 
characteristics,  and  representations  of  data  elements 
according  to  established  procedures  and  conventions. 

Data  Element  Standards.  The  standardization  and  management  of 

data  element  definitions,  formats,  content,  and  relationships 
between  data  elements. 

Data  Entity.  An  object  of  interest  to  the  enterprise,  usually 
tracked  by  an  automated  system.  (KBS  Special  Pub  500-149) 

Data  File.  All  data  elements  comprising  a  single  table  of 
information  relating  to  a  data  entity. 

Data  Fill.  The  actual  data  (or  lack  of)  in  the  data  element 
fields. 

Data  Merging.  The  ability  to  combine  data  from  multiple 

digitized  sources.  A  prerequisite  to  computer  data  merging 
is  deconfliction  of  data  element  standards  and  database 
structure. 

Data  Model.  In  a  database,  the  user's  logical  view  of  the  data 
in  contrast  to  the  physically  stored  data,  or  storage 
structure.  A  description  of  the  organization  of  data  in  a 
manner  that  reflects  the  information  structure  of  an 
enterprise.  (FIPS  Pub  11-3) 

(1)  Logical  Data  Model.  A  model  of  the  data  stores  and  flows 
of  the  organization  derived  from  the  conceptual  business 
model.  (NBS  Special  Pub  500-149) 

(2)  Physical  Data  Model.  A  representation  of  the 
technologically  independent  requirements  in  a  physical 
environment  of  hardware,  software,  and  network  configurations 
representing  them  in  the  constraints  of  an  existing  physical 
environment . 

Data  Set.  A  group  of  data  elements  that  collectively  describe  a 
composite  object,  e.g.,  platform,  weapon,  sensor, 
installation,  or  other  object. 
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Data  Sat  structure.  A  representation  of  the  logical 

relationships  that  exist  among  the  data  elements  comprising 
the  data  set.  The  data  set  structure  defines  unique 
identifiers  within  the  data  set,  subordinate  relationships, 
repeating  or  multi-valued  occurrences,  and  coded  or 
constrained  elements. 

Data  Structure.  The  logical  relationships  which  exist  among 

units  of  data  and  the  descriptive  features  defined  for  those 
relationships  and  data  units;  an  instance  or  occurrence  of  a 
data  model.  (NBS  Special  Pub  500-152) 

Data  Translation.  The  computer  conversion  of  one  data  element 
format  into  another  format;  e.g.,  truncation  of  the  30 
character  ship  name  field  into  a  26  character  field  for  use 
by  a  hardware  and/or  software  constrained  system. 

Database.  A  collection  of  interrelated  data,  often  with 

controlled  redundancy ,  organized  according  to  a  schema  to 
serve  one  or  more  applications;  the  data  are  stored  so  that 
they  can  by  used  by  different  programs  without  concern  for 
the  data  structure  or  organization.  A  common  approach  is 
used  to  add  new  data  and  to  modify  and  retrieve  existing 
data.  (FIPS  Pub  11-3) 

Defense  Data  Repository  System  (DDRS) .  The  database  administered 
by  the  Center  for  Information  Management  for  managing  the 
submission,  review,  and  approval  of  DOD  standard  data 
elements. 

Information.  Any  communication  or  reception  of  knowledge  such  as 
facts,  data,  or  opinions,  including  numerical ,  graphic,  or 
narrative  forms,  whether  oral  or  maintained  in  any  medium, 
including  computerized  databases,  paper,  microforms,  or 
magnetic  tape.  (DODD  8000.1  of  27  October  1992  (NOTAL) ) 

Information  Architecture .  A  database  schema  of  information 

categories  (data  sets)  containing  standardized  data  elements 
with  designated  data  sources.  The  information  architecture 
in  the  NWTDB  Data  Standards  and  Structures  Manuals  is  a  guide 
for  defining  essential  elements  of  information  to  support 
operational  functionality,  and  for  internal  system  design  to 
achieve  a  common  relational  database.  The  NWTDB  structure  is 
hardware  and  software  independent. 

Information  standards.  The  standardization  of  data  elements, 
database  structure,  message  text  formats,  and  tactical 
digital  information  links. 
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Information  System.  The  organized  collection,  processing, 

maintenance,  transmission,  and  dissemination  of  information 
in  accordance  with  defined  procedures,  whether  automated  or 
manual.  (DODD  5200.28  of  21  March  1988) 

Integrated  Database  (IDB)  -  Transaction  Format  <TF) .  IDB-TF  is  a 
DIA  approved,  generalized  transaction  structure  which  is  used 
to  communicate  Integrated  Database  maintenance  data  between 
IDB  systems. 

Interface.  A  boundary  or  point  common  to  two  or  more  command  and 
control  systems  or  subsystems,  communication  systems  or 
equipment,  or  other  entities  across  which  necessary 
information  flow  takes  place.  A  joint  interface  implies  that 
the  boundary  is  shared  by  two  or  more  services/agencies.  A 
combined  interface  is  shared  by  entities  from  one  or  more 
U.S.  services/agencies  and  an  allied  nation. 

(1)  Technical  Interface.  A  specification  of  the  functional, 
electrical,  and  physical  characteristics  necessary  to  allow 
the  exchange  of  information  between  systems.  An  Interface 
Requirements  Specification  (IRS)  is  used  to  specify  the 
functional  and  physical  requirements  of  an  interface  between 
systems;  DI -MCCR- 8 0 0 2 6 A  pertains.  An  Interface  Design 
Document  (IDD)  is  used  to  describe  the  detailed  design  of  the 
requirements  within  the  IRS;  DI-MCCR-80027A  pertains. 

Warfare  System  Controlled  Interface  Documents  (WSCIDs)  are 
used  to  describe  functional,  physical,  and  electrical 
interface  characteristics . 

(2)  Procedural  Interface.  A  specification  for  accomplishing 
exchange  of  information  across  an  interface;  e.g.,  OPSFEC 
411,  OPSPEC  516,  OPSPEC  OTG.  A  procedural  interface  defines: 

(a)  The  form  or  format  in  which  information  is  to  be 
exchanged. 

(b)  The  prescribed  information  exchange  language,  syntax, 
and  vocabulary  to  be  used  in  the  information  exchange. 

(c)  The  operating  procedures  that  govern  information 
exchange. 

Interoperability.  The  ability  of  systems,  units  or  forces  to 

provide  services  to,  and  accept  services  from,  other  systems, 
units  or  forces,  and  to  use  the  services  so  exchanged  to 
enable  them  to  operate  effectively  together  (JCS  Pub  1) . 
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Naval  Warfare  Tactical  Database  (NWTDB) .  (1)  The  management 

process  to  evolve  to  the  common  tactical  database  that  meets 
the  needs  of  the  Composite  Warfare  Commander  and  Joint  Task 
Force  Commander,  supporting  naval,  joint,  and  combined 
operations.  (2)  The  authoritative  tactical  database,  or 
subsets  thereof,  distributed  by  designated  producers  in 
accordance  with  the  information  architecture  contained  in  the 
functional  volumes  which  comprise  the  NWTDB  Data  Standards 
and  Structures  Manuals.  Coordination  of  standards  and 
structure  permits  the  merging  of  data  from  multiple 
producers . 

Tactical  Information  Interoperability.  The  ability  of  tactical 
naval  warfare  systems  to  use  approved  joint  and  Navy 
information  standards,  especially  tactical  data  information 
links,  message  text  formats.  Naval  Warfare  Tactical  Database 
(NWTDB) ,  and/or  Over-the -Horizon  Gold  formats. 

Tactical  Naval  Warfare  System  (TNW8) .  Any  C3,  Intelligence 

(includes  surveillance) ,  or  Combat  system  that  supports  naval 
warfare. 
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INTERIM  NWDTB  USER  FEEDBACK/ REQUIREMENTS  REPORT 
Following  items  are  keyed  to  report  paragraph  numbers. 


1.  USER  IDENTIFICATION .  Identify  the  user  command  and  point  of 

contact.  Include  mail  and  message  addresses  plus  telephone  and 
facsimile  numbers _ _ 

2.  SYSTEM  AND  DATA  PRODUCT  IDENTIFICATION.  Identify  name,  ” 
edition  or  version  of  the  data  product  and  system (s)  involved. 

3.  DATA  REQUIREMENT  OR  FEEDBACK  REPORT.  Identify  new  or 

changed  requirement  or  rate  a  product's  required  performance  in 
specific  operational  environments  and  applications.  This 
should  include  the  full  range  of  product  characteristics 
including  media  and  user  documentation.  _ _ _ 

4.  IMPACT  ASSESSMENT.  Operational  impact  is  defined  in  terms 
of  the  current  and  potential  operational  impacts  on  users. 
Assess  impact  for  both  the  system  in  question  and  the  network 
of  affected  systems.  Make  specific  projections  for  wartime  and 
crisis  situations  based  on  experienced  or  projected  increased 
activity  and  availability  of  backup  capability  in  those  cases. 

5.  CAUSAL  ANALYSIS.  Identify  known  and  suspected  causes  for 
the  problem.  Relate  to  specific  applications  and  functions, 
software,  or  hardware  and  analyze  in  sufficient  detail  to 
support  impact  assessment  and  corrective  actions.  Typical 

content  includes  the  following: _ _ _ 

5. a  INFORMATION  REQUIREMENTS  ANALYSIS!  Briefly  describe  ” 

information  requirements  not  being  fulfilled,  since 
requirements  change  as  systems  and  situations  evolve,  this 
analysis  should  identify  new  or  significantly  changed 

requirements.  Reduced  requirements  are  important. _ 

5.b  OPERATIONAL  SUPPORT  ANALYSIS.  Review  relevancy  and 
timeliness  of  the  database  performance  and  information  outputs 
in  terms  of  satisfying  command  and  control  and  targeting  needs. 
S.o  STRUCTURE  AND  FILL  ANALYSIS.  Identify  and  analyze  database 
structure,  fill,  and  related  processing  associated  with  the 
reported  problem.  This  includes  ability  to  interface  with 
related  systems,  internal  and  external  communications,  and 
operational  procedures.  Relevant  factors  include,  but  are  not 
limited  to:  (a)  completeness  in  terms  of  the  full  range  of 
information  needs  (b)  redundant  data;  (c)  non-standard  formats 
or  addresses;  (d)  errors  in  content;  (e)  errors  in  structure; 

and  (f)  errors  in  correlation/track  management. _ 

5.d  HUMAN  FACTORS  ANALYSIS.  If  applicable,  address  the  problem 
in  terms  of  ease  of  use,  training,  or  experience,  availability 
or  suitability  of  documentation,  time  required  for 
interpretation  of  outputs,  etc. 
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5.  •  ARCHIVING  AND  LOGGING  CAPABILITY  ANALYSIS.  System 

archiving  and  logging  capabilities  inherent  in  the  product 
under  consideration  will  be  analyzed  in  terms  of  completeness 
and  responsiveness.  A  key  issue  is  whether  or  not  the  integral 
system  capability  supports  rapid  detection,  documentation,  and 
resolution  of  problems. _ _ _ 

6.  SOLUTION  DEVELOPMENT.  When  possible,  preferred  solutions 

should  be  proposed  in  context  of  importance  and  urgency.  Major 
deficiencies  are  normally  resolved  by  whatever  means  possible 
and  then  reported.  Minor  deficiencies  are  more  frequently  put 
into  the  appropriate  support  channels  and  worked  around  until  a 
permanent  solution  is  received.  Given  the  need  for  inter- 
platform  and  inter-theater  interoperability,  all  solutions 
should  be  assessed  for  their  impact  on  Navy,  joint,  and 
combined  operations. _ 

7.  IMPLEMENTATION  AND  MONITORING.  Report  whether  special 
implementation  and  monitoring  actions  are  necessary.  Identify 
actions  already  taken  to  report  and  resolve  the  issues. 
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Note:  Message  nay  be  used  for  urgent  feedback. 

Ser  xxx/ 


From: 

To:  (Functional  Database  Manager,  if  known.  If  not,  send 

to  ONI -7 3  for  determination  and  action.  Addresses 
listed  below. 

Subj :  NAVAL  WARFARE  TACTICAL  DATABASE  FEEDBACK  REPORT 

Ref:  (a)  OPNAVINST  9410.6,  "Naval  Warfare  Tactical 

Database  (NWTDB)  Requirements  for  Tactical  Naval 
Warfare  Systems . " 

Enel:  (1)  NWTDB  Requirement  (or  Report)  Number  CY-xx 

(Use  calendar  year,  followed  by  two-digit  sequential  number, 
starting  with  01  each  calendar  year,  e.g.  94-03.) 

1.  The  following  NWTDB  requirement  (or  report)  is  forwarded 
as  provided  in  reference  (a) . 


1.  USER  IDENTIFICATION. 

2.  SYSTEM  AND  DATA  PRODUCT  IDENTIFICATION. 

3.  DATA  REQUIREMENT  OR  FEEDBACK  REPORT. 

4.  IMPACT  ASSESSMENT. 

5.  CAUSAL  ANALYSIS. 

a.  INFORMATION  REQUIREMENTS  ANALYSIS. 

b.  OPERATIONAL  SUPPORT  ANALYSIS. 

C.  STRUCTURE  AND  FILL  ANALYSIS. 

d.  HUMAN  FACTORS  ANALYSIS. 

e.  ARCHIVING  AND  LOGGING  CAPABILITY  ANALYSIS. 

6.  SOLUTION  DEVELOPMENT. 

7.  IMPLEMENTATION  AND  MONITORING. 


Copy  to: 

CNO  (N65) 
ONI-73 

NCTSI  (Code  5) 
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IIWTDB  REQUIREMENTS  END  FEEDBACK  REPORT  ADDRESSES 

PLATFORMS/SYSTEMS  CHARACTERISTICS  AND  PERFORMANCE  DATA  -  NID 

Director,  Office  of  Naval  Intelligence 
Attn:  ONI -2 2 2 
4301  Suitland  Road 
Washington  D.C.  20395-5000 


RADAR  PARAMETERS  DATA  -  RAPADS 

Officer  in  Charge,  Electronic  Warfare  Operational 
Programming  Facility  (EWOPFAC) 

5100  Relay  Road 
Chesapeake,  VA  23322-4499 


OCEANOGRAPHIC  AND  METEOROLOGICAL  DATA  -  OAML  AND  NODDE8 

Commander,  Naval  Oceanography  Command 

Attn:  Code  N522 

1020  Balch  Boulevard 

Stennis  Space  Center,  MS  39529-5000 


MILITARY  INTELLIGENCE  DATA  -  MIIDS/IDB 

Atlantic  Intelligence  Command 
Attn:  Code  IS7 
7941  Blandy  Road,  Ste  100 
Norfolk,  VA  23511-2498 

or:  Joint  Intelligence  Center,  Pacific 

Attn:  RD 
Box  500 

Pearl  Harbor,  HI  96860-7450 


CRYPTOLOGIC  DATA  -  CCDB 

Commander,  Naval  Security  Group  Command 
Attn:  G32 

Naval  Security  Group  Command  Headquarters 
3801  Nebraska  Avenue,  N.W. 

Washington,  DC  20393-5210 
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MODELING  AMD  SIMULATION  DATA 

Commander,  Space  and  Naval  Warfare  Systems  Command 
Attn:  SPAWAR  31 

2451  Crystal  Drive 
Arlington,  VA  22245-5200 


•  Copy  to  (except  cryptologic) : 

Chief  of  Naval  Operations 
Attn:  CNO  (N65) 

Department  of  the  Navy 
Washington,  DC  20350-2000 

Director,  Office  of  Naval  Intelligence 
Attn:  ONI-73 
4301  Suit land  Road 
Washington,  DC  20395-3000 

Commanding  Officer,  Navy  Center  for  Tactical  Systems 
Interoperabil ity 
Attn:  Code  5 

53690  Tomahawk  Drive,  Suite  125A 
San  Diego,  CA  92147-5082 
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Geospatial  Feature  Attribute  Geospatial  Feature  Representation 

Release  Restriction  Release  Restriction 


DMA  Not  Alone! 
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DoD  Joint  Effort  to  Standardize 
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Eliminates  duplication  of  effort 

-  Overall  savings  (time  and  $)  within  DoD 

Data  Elements  that  everyone  can  use 
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Program  Acquistion  Cycle 
Tasks:  To  do  Analyses  of  weapons  systems  and 

Deliver  the  results  in  different  formats 


Air  Force  Studies  &  Analyses  Agency 


439 


V) 

o 

"D 

O 

E 

o 

3 

a 

E 

o 

o 


T3 

t 

O 

a 

a 

3 

CO 

CO 

9mm 

CO 

‘<0 

jjs 

CO 

c 

< 


*1 

a  a) 

E  E 

|  I 

I  = 

c  o> 
o  o> 

(A  C 
T3  j2 

go 

v 
TJ  (A 
Q)  0)  (A 

«?» 
JE  | 


o> 

O) 

(0 


o  g 

.  o  a, 

4_i  (0 

O  Q.  C 
«  C  O 
is  •=  Q. 
10  m  (B 

<  «A  > 


c  2 

13 

Erf 

0)  o 
«>  _r 

o  ® 

C  CA 
©  O 

CO 

e  eg 

fl)  CO 
CA  <U 
0)  0 
Q.  O) 

qT  c 

C  (0 

2  O 
0)  — 

fg 

E  o 
o  s= 
o  o 
^  c 

8*2 

E  c 

Tf  CL 

a>  co 
=  a> 

2  * 

2  *- 
o  o 


evaluate  the  "global  value"  of  the  change,  as  the  value 
is  scenario  dependent 


440 


LL 

$ 

Q 


ID 


Air  Force  Studies  &  Analyses  Agency 


441 


c 

3 

t 

< 

O 

CO 

Q. 

Q. 

o 

o 

\a 

c 

c 

o 

■  MB 

5 

o 

o 

CD 

l. 

zz 

3 

o 

O 

o 

o 

CD 

CO 

JO 

C0 

■  MBI 

iS 

CO 

C0 

* 

"O 

o 

o 

< 

N 

■  ■M 

CO 

"ji 

c 

c 

3 

CD 

o 

•  • 


"O 

3 

0? 

Q. 

0) 


m 

O 

O 

C 

0) 

E 

0) 

U> 

(0 

C  t 
(0  fl> 

is 

O  E 


<o 

» 

>» 

re 

>  re 

S  o 

CO 
Q. 

0) 


JO 

O 

O 

C 

o 

E 

0) 

O) 

<0 

c 

(0  fc. 

E  ® 

I"  O) 
>»  (0 

T*  c 

3 

5)  E 


J0 

a  co 
CO  42 

=5  3 

ts  & 

.2  o 


(0  C 
Jz  * 

o  w 

S  S 
0)0 

o  ^ 


<0  w 
5?  c 

li 

O  w 


study  and  display  results 


Air  Force  Studies  &  Analyses  Agency 


i 


DRAFT 


Air  Force  Studies  &  Analyses  Agency 


443 


u. 

2 

D 


oo 


Air  Force  Studies  &  Analyses  Agency 


Air  Force  Studies  &  Analyses  Agency 


445 


<0 

o 

o 


o 

(0 

Q) 

5 

(0 

o 

o 


MM 

(D 

c 

O) 

o 

E 

S 

o 

o 

0? 

u> 

(A 

05 

(A 

CO 

c 

05 

E 

E 

00 

2 

o 

0) 

<0 

3 

05 

a 

E 

5 

o 

O 

05 

I 

Q 

l 

• 

<A 

0 

(A 

co 

.n 


a 

(0 

“O 

c 

"<5 

4-> 

c 

’co 

E 


00 


I 


0) 


0) 

o> 

05 

c 

05 


study  manager  and  data  manager,  may  cause 
slower  reaction  time  to  ‘set  up’  process 


Air  Force  Studies  &  Analyses  Agency 


Air  Force  Studies  &  Analyses  Agency 


3 

cr 

a> 

O' 

CD 

a 

OL 

a. 


c 

Ui 

'</> 

0) 

o 


o 


«  - 


E  S 

O  a> 

•5  i 

co 

CD  c 

DC  s 

®  <3 
c  (o 
mZ  Q 
O 

Q 


c  a 
£  c/> 

E  5 

a> 

O)  o 
co 

c  a 


CO 

CD 

c 


0 

E 


CO 


CO 


“  O) 

3  * 
^3  CO 


I  I  I 


B 

CO 

0 


0 

"O 

o 


cd 

CD  >* 

0  CD  Z,  «  £  ~ 


C 

o 


5-  0 


o> 

0 


c  c 


0  0 

2  3 

bo  iS  5 
<0  (0 
Ui  LU 


449 


Ba&BSS 


Joint  Data  Base  Elements  for 
Modeling  &  Simulation  (JDBE) 


Data  Sharing  and 
Standardization 


/  through 

/ 

/ 

/ 

j  Information  Modeling 


•  Develops  candidate  standard  data  elements 
and  data  models  for  Modeling  and 
Simulation. 

*  Provides  the  Modeling  and  Simulation 
community  with  a  reverse-engineering  data 
modeline  methodolo 


*  Provides  a  methodology  for  the  creation  of 
inteerated  schemas  to  share  data  between 


data  bases. 

•  Creates  a  Military  Handbook  with  a  living 
electronic  appendix. 


Page  1 


•  Bottom  -  Up  Using  Existing  Data  Bases 

•  Involve  Data  Base  Developers  and  Users 

•  Apply  IDEF1X  Data  Model  Methodology 

•  Create  Integrated  Data  Models  by  Subject  Area 

•  Interface  with  Top-Down  CIM  Data  Models 
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Reverse  Engineering 
Approach 


vAiiw.vimw.'AwVAWMVWiViWi'A 


•  Bottom-up,  instead  of  top-down  analysis. 

•  Addresses  existing  data  resources. 

•  Incremental,  one  bite  at  a  time! 


Threat  Organization 


Missiles 


Electromagnetics 


Terrain  Features 
Vehicles 
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JDBE  Project  Status 


ITEM 


Military  Handbook 

SAI  Model  for  Electromagnetic 
Equipment  Characteristics 

Data  Dictionary/Diiectoiy  Tools 

Data  Repository  (Interim  Design) 


□ 


STATUS 


■  Draft  Completed 


-  First  Version  Completed 

-  Demo  Version  Working 

-  Being  Populated 
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Purpose  of  the  Handbook 

•  Provides  Guidance  \  c 

>  Subject  Area  Information 

•  Describes  Procedures  J  Models  via  jdbe  process 

•  Method  for  Reverse  Engineering  of 
Existing  Data  Bases  Using  IDEF1X 

•  Method  for  Integration  of  Resulting 
Project  Information  Models 

•  For  M&S  Data  Base  Activities 

(or  any  other  information  modeling) 


JDBE  Military  Handbook 

wmmm 


R 


I 
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*  Draft  Includes  Printed  Examples  from  JDBE  Proof  of 
Concept  SAI  Model  for  Electromagnetic  Equipment 
Characteristics 

-  Data  Dictionary 

»  1DEF1X  Diagram* 

*  Entity  Tables  and  Definition* 

»  Attribute  Tables  and  Definitions 

-  Data  Directoiy 

»  Data  Sources 
»  Descriptions 
»  PCX!  Information 

•  Computer  Files  to  be  Published  Separately 


wwi 


ata  Dictionary/Directory 
(Cont.) 


•  Electronic  appendix  to  the  Military  Handbook 

•  PC-based  software  (MS-DOS/Windows) 

•  Data  base  of: 

-  Data  elements  and  descriptions 

-  Data  entities  and  descriptions 

-  Current  data  bases 

-  Current  Modeling  and  Simulation  projects 

•  Royalty-free  distribution 

•  Stand-alone 
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Server  version 

-  JDBE  woiking  repositoiy 

-  DBMS  back  end 

Stand  alone  version 

-  Requires  ERwin 

-  Project  data  models 

-  SAI  model 

-  Mappings 

Read  only  version 

•  Help  file  format 

-  Electronic  copy  of  Mil-Handbook  and  Appendixes 


Potential  JDBE  Efforts  for 


DMSO 


Extension  of  JDBE  Methodology 

-  8320  Series  Implementation 

-  Complex  data  types 

Refinement  of  Data  Dictionary  Tool 

-  Data  element  submission 

-  Automated  mapping  tool 

-  Complex  data  Types 

Metrics 

DoD  Standardization  Program 

-  Data  Modeling  Assistance  to  projects 

-  Technical  support  on  IDEF1X  and  ERwin  to  projects 
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JDBE  Support  to  Other 
Projects 


•  UTSS 

-  IDEF1X  and  ERwin  Training 

-  Data  Modeling 

-  Data  Base  Design 

-  Consulting  Technical  support 

•  MICOM 

-  IDEF1X  and  ERwin  Training 

-  Data  Modeling  Consulting  (possible) 

•  CCrr  and  CENTCOM  (possible) 
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Kquipmcnl  Characteristics  Dalii  Hum1  ( Version  2.0 1 
Functional  Overview 
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METL  (CATTTASK) 


Launching  from  Windows  Menu 


Equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


Official  Use  Only  Screen  -  Press  and  continue 


Equipment  Characteristics  Dala  Base  (Version  1.1  -  Alpha  Test) 


CATT  Wallpaper  (Image  Only) 


Iu|tii|)mcni  (liaiacteristics  Data  Base  (Version  1. 1  -AlphaTest) 


ECDB  Opening  Selection  Screen 


F.c|uipmeni  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


Opening  Program  Selection  Pull  Down  Menu 
(The  CCTT  Program  is  selected) 


Equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


Opening  Type  of  Force  Selection  Full  Down  Menu 
( The  Type  Is  selected) 


Equipment  Characteristics  Data  Base  (Version  1. 1  -  Alpha  Test) 


(The  Equipment  can  be  selected) 


Equipment  Characteristics  Data  Base 


RCI,  Orlando,  FLorida 


Equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


Ml  Equipment  Main  Parts  Data  Screen  Opened 


Equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


Ml  Equipment  Data.  Menu  Screen  Opened 


(iquipmcnt  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 
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Ml  General  Data  Information  Screen  Displayed 


Equipment  Characteristics  Data  Base  (Version  1. 1  -  Alpha Test) 
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Ml  Equipment  Purpose  Data  Screen  Opened 


equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 
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Characteristics  Data  Menu  Screen  Opened 


Equipment  Characteristics  Data  Base  (Version  1.1  -  Alpha  Test) 


TABEL  A-l  Data.  Editor  and  Report  Generator  attached  to  ECDB  Main  Data  Engine 


473 


(This  page  intentionally  left  blank) 


474 


An  ECDB  Overview ... 


Welcome  to  ECDB  2  for  Windows 
What  the  ECDB  2  provides 
Current  ECDB  2  features 
What  to  expect  mth  ECDB  2 


T his  chapter  explains  the  standard  features  of  the 
ECDB  and  briefly  tells  you  what  to  expect  from 
this  alpha-test  version.  After  you  installed  your 
ECDB  (Section  2)  and  registered  your  ECDB  copy 
with  PM-CATT  (Section  3),  you  can  refer  to  this 
User's  Guide  for  complete,  step-by-step 
instructions  for  all  software  operations 

(Section  4). 
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An  ECDB  Overview ... 


Welcome  to  ECDB 
for  Windows  .... 


What  the  ECDB 
provides.... 


as  of :  7  December,  1993 


1 


PM-CATT  welcomes  you  to  the  Equipment  Characteristics  Data  Base 
(ECDB).  As  you  start  using  the  ECDB ,  you  soon  discover  that  is  it 
very  easy  to  use  whether  you're  in  management,  research  or  software 
programming.  As  you  begin  using  the  ECDB ,  PM-CATT  will  encourage 
its  ECDB  subscribers  to  participate  in  the  expansion  of  the  programs 
functionality,  capabilities  and  data  base. 


The  ECDB  is  a  living  data  library  initially  built  for  CCTT  Specification 
Table  A-l  equipments.  Being  a  living  data  library,  the  ECDB  data  will 
be  forever  growing  by  data  contributions  from  Subject  Matter  Experts 
to  contractor's  data  deliverables.  To  support  this  data  growth,  the 
ECDB  has  a  robust  open  architecture  permitting  it  to  function  on  four 
different  levels.  These  functional  levels  provide  : 

General  information  used  by  management  about  the  equipment  that  will  be  or 
is  being  simulated 

Specific  data  used  by  analysts  for  developing  algorithms  or  where  to  locate 
additional  information  in  the  PM-CATT  library  system 

IGES  engineering  drawings  used  by  the  visual  data  base  programmers  who 
must  create  and  store  the  equipment's  simulator  image  or  those  people  required 
to  use  engineering  drawings  in  their  work  (i.e.  logistics  engineers,  technical 
writers) 

Reuse  of  stored  information,  illustrations  and  engineering  drawing  files  to  be 
used  by  all  ECDB  users. 


M/m 
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An  ECDB  Overview ... 


1 


Current  ECDB  2 
features  ... 


ECDB  2  for  Windows  is  an  alpha-test  version  that  is  capable  of 
providing  basic  user  functions  and  preliminary  information  about  the 
Table  A-l  equipments.  As  the  ECDB  matures,  the  features  below  will 
become  the  standard  ECDB  features. 

Open  CALS  architecture 

The  ECDB  design  meets  the  process  requirements  of  MIL-HDBK-59B 
Computer-aided  Acquistion  and  Logistics  Support  (CALS)  Implementation 
Guide.  These  requirements  provide  guidelines  for  common  interfaces  and 
neutral  file  formats  necessary  for  the  effective  access,  interchange  and  use  of 
digitial  data.  The  cornerstone  of  this  effectiveness  is  the  application  of  the 
Integrated  Weapon  System  Database  (IWSDB)  to  provide  the  open  acrhitecture 
for  ECDB.  This  open  architecture  permits  PM-CATT  to  create  and  manage  a 
living  data  base. 

Living  Data  Base 

ECDB  has  two  functional  components.  The  first  component  is  resident  on  your 
computer  and  the  other  component  resides  at  PM-CATT.  The  component  on 
your  computer  is  the  data  engine.  This  engine  processes  your  searches, 
comparisons,  requests  data  downloads,  and  makes  reports.  The  second 
component  is  the  living  data  base  (because  ECDB  data  is  growing  and 
maturing  on  a  daily  basis).  By  having  a  living  data  base,  ECDB  users  are 
assured  that  the  information  is  current,  and  the  need  for  installing  new  a 
ECDB  everytime  the  data  is  upgraded  is  eliminated. 

Graphics 

To  assist  the  user,  ECDB  supplies  illustrations  showing  the  front,  side,  rear, 
isometric  (3-D)  and  photo  of  the  equipment  selected.  Please  remember  that  this 
is  an  evolving  and  maturing  database,  not  all  equipment  will  have  graphics. 
Remember  that  die  quality  of  all  ECDB  graphics  are  directly  dependent  on  your 
monitor  and  printer. 

In  keeping  with  the  CALS  initiatives,  ECDB  graphic  files  are  transportable  to 
your  computer  for  reuse.  These  graphics  are  suitable  for  use  in  view  graph 
presentations  and  engineering  and  management  reports  only.  Users  are 
encouraged  to  contribute  either  better  quality  graphics  or  additional  graphic 
views  to  this  PM-CATT  graphics  library. 


as  of  :  7  December,  1993 
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An  ECDB  Overview ... 


Features ... 


IGES  Engineering  Drawing  Reuse  Library 

The  ECDB  2  for  Windows  features  the  capability  for  the  user  to  read,  edit  and 
receive  IGES  or  CALS  engineering  drawings.  These  engineering  drawings  are 
supplied  directly  from  TACOM,  AMCCOM,  etc.  and  stored  in  the  ECDB 
Engineering  Drawings  Library. 


The  ECDB  library  maintains  top  level  engineering  and  outline  drawings  for 
equipment  For  the  analysts,  the  top  level  engineering  drawings  provide  a 
method  to  validate  equipment  configurations  and  part  numbers.  For  the  visual 
database  programmer,  the  outline  drawings  can  be  used  to  create  polygon 
drawings  for  use  in  their  image  generators. 

IGES  Polygon  Reuse  Library 

As  the  visual  programmers  for  CCTT  complete  the  polygon  images  for  their 
simulators,  they  will  transmit  these  images  to  PM-CATT  ECDB  for  library 
storage  and  reuse.  The  contractor  will  transmit  two  types  of  images.  The  first 
will  be  the  IGES  generic  polygon  image  drawings  needed  for  reuse  by  other 
contractors.  The  second  image  will  be  a  "TIE  Format”  image  showing  the 
rendered  image  of  the  generic  polygon  file.  Since  this  is  a  living  database, 
these  drawings  will  be  available  to  library  users  upon  reciept  from  the  software 
developers. 

Other  than  Table  A-l  Equipment 

The  ECDB  2  for  Windows  primary  function  is  to  support  that  equipment 
identified  on  Table  A-l.  Although  the  Table  A-l  equipment  list  is  impressive,  it 
does  not  reflect  the  entire  inventory  of  equipment  available  to  military  analysts 
and  planners  during  tactical  operations. 


To  assist  these  military  planners  and  analysts,  the  ECDB  2  will  have  general 
information  on  the  non-Table  A-l  equipments.  This  is  to  correct  potential 
problems  on  misidentfying  equipment  ECDB  users  must  expect  limited 
information  of  parts  information  and  some  general  characteristics  (i.e.  speed, 
weight).  Graphics  illustrations  of  these  equipments  will  be  limited.  The  ECDB 
IGES  library  is  not  required  to  acquire  these  files.  However,  the  ECDB  library 
will  accept  data  and  IGES  drawing  donations  to  enhance  the  PM-CATT 
capabilities. 

Print 

In  the  alpha-test  versions  of  ECDB  2,  this  feature  will  not  be  available.  As  an 
alpha  test  user,  you  are  encouraged  to  work  with  the  ECDB  architect  to  design 
specific  and  general  use  reports  for  your  community. 


as  of :  7  December,  1993 
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An  ECDB  Overview ... 


Features  ... 


1 


Model  companions 

To  help  managers  and  analysis,  the  ECDB  2  for  Windows  will  have  the 
capability  to  compare  characterisics  of  several  pieces  of  equipment.  At  the  time 
of  the  first  alpha  test  versions  of  ECDB  2  this  feature  will  be  available.  Alpha 
test  users  are  encounaged  to  work  closely  with  the  ECDB  architect  in 
suggesting  companion  reports  beneficial  to  your  area  of  interest. 

Government  Integrated  Technicial  Information  System 
(GUIS)  &  Contractor's  Integrated  Technical 
Information  Services  (CITIS)  Functionality. 

An  ECDB  2  for  Windows  important  design  feature  is  its  open  architecture  that 
is  transparent  to  the  user.  Since  the  ECDB  architecture  is  fully  CALS 
compliant,  the  ECDB  has  created  a  baseline  GUIS  backbone  that  can  provide 
data  downloading  (re:  MIL-C-CITIS). 

This  GITIS  functionality  will  permit  the  ECDB  to  have  active  data  links  to 
other  PM-CATT  data  librarys  resident  at  RCI.  The  libraries  to  be  linked  are 
DOCATS,  CATT  Tracker,  and  CATT  Task. 

In  the  future,  PM-CATT  and  ECDB  users  could  benefit  from  the  ECDB  GITIS 
functionality  because  it  maximizes  the  reuse  of  logistics  data  and  IGES 
drawings  in  the  PM-CATT  libraries.  With  the  GITIS  functionality,  the  ECDB 
could  be  enhanced  to  manage  all  PM-CATT  logistics  and  maintenance 
engineering  and  field  data  under  one  common  file. 

Screen  Colors 

The  ECDB  2  for  Windows  screen  colors  are  under  automatic  control  from  your 
Windows  3.1  Control  Panel.  An  architectural  decision  was  made  to  avoid 
fixing  screen  colors  during  the  early  phases  of  product  development.  It  is  the 
designers  intent  to  present  dynamic  screen  images  after  the  design  is  solidified. 
We  request  your  suggestions  about  these  matters. 
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What  to  expect 
from  ECDB  2  . . . 

alpha  test  version 


With  this  release  of  ECDB  2  for  Windows,  ECDB  transitions  from  an 
academic  prototype  FoxPro  for  DOS  product  to  open  architecture  and  Wide 
Area  Network  (WAN)  FoxPro  for  a  Windows  product.  With  this  transition  to 
the  windows  environment,  the  ECDB' s  has  greatly  increased  functionality, 
connectivity,  and  capabilities,  not  easily  achievable  under  DOS. 

In  the  early  software  development  phase  of  ECDB  2  for  Windows,  the  PM- 
CATT  has  requested  to  have  this  program  available  on  the  WAN  as  soon  as 
possible.  To  meet  these  requests,  the  ECDB  2  is  released  as  a  alpha-test 
version.  To  the  user,  this  version  of  the  ECDB  will  function  close  to  the  final 
product,  but  requires  some  final  software  adjustments  and  testing.  A  benefit  of 
the  alpha-test  version  encourages  users  to  participate  in  product  improvements 
and  data  expansion.  By  working  together,  this  product  will  mature  quickly  and 
become  a  valuable  tool  for  research  and  development  In  summary,  here  is 
what  you  can  expect  with  this  version. 

Performance 

The  alpha-test  version  of  ECDB  2  for  Windows  will  function  at  approximately 
65%  of  its  planned  functionality.  The  focus  of  the  ECDB  development  efforts 
have  been  the  creation  and  functional  testing  of: 

O  User  friendly  navigational  menus  and  user  designed  tools. 

O  Validating  core  parts  information  for  Table  A-l  equipment 

O  Graphics  storage  capabilties  and  quality  levels. 

O  Creating  internal  data  management  tools  that  could  be  reused  for 
for  PM-CATT  community  use. 

FoxPro  for  Windows  Limitations 

PM-CATT  selected  FoxPro  2.5  for  Windows  as  the  data  base  platform  for  all 
PM-CATT  contracts.  FoxPro  is  an  excellent  platform  for  data  base 
applications  and  provides  excellent  connectivity  to  other  PM-CATT  data 
bases. 

The  ECDB  2  for  Windows  design  is  pushing  the  outer  limits  of  the  current 
FoxPro  2.5  capabilities.  The  ECDB  has  experienced  file  size  limitations  when 
handling  high  resolution  illustrations  for  possible  future  reuse  in  technical 
manuals.  Working  within  those  limitations,  the  ECDB  graphics  are  suitable 
for  management  reports,  view  graphs  or  analytical  studies.  It  is  anticipated 
that  some  future  releases  of  FoxPro  for  Windows  could  correct  these 
limitations. 
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IGES  Drawings 

Any  IGES  drawing  in  the  ECDB  library  are  stored  in  '  as  recieved"  condition 
as  supplied  by  the  Program  Mangaers.  PM-CATT  can  not  assume 
responsiblity  for  the  accuracy  of  these  drawing.  PM-CATT  will,  however, 
provide  a  point  of  contact  for  the  user  to  contact  the  originator  of  these 
engineering  drawing. 

Data  Population  and  Population  Schema 

Like  any  new  complex  information  system,  the  data  must  be  gathered, 
assimulated  and  presented  to  the  users  in  straightforward  and  simple  manner. 
The  ECDB  is  no  exception.  Careful  planning  and  scheduling  of  data 
population  will  make  ECDB  a  success  and  beneficial  tool. 

Help  Us.....  Help  You. _ 

At  first,  the  ECDB  alpha  test  users  must  expect  that  the  ECDB  may  not 
answer  all  their  questions.  When  an  alpha  test  user  locates  an  area  that  they 
can  contribute,  they  will  be  expected  to  help  PM-CATT  populate  that  area. 

Population  Schema _ _ 

To  request  data  from  others  and  have  nowhere  to  immediately  reuse  the  data 
is  poor  planning.  The  ECDB  plan  or  schema  is  to  provide  an  accessible  home 
for  data  and  create  a  common  dialogue  tool  for  everyone  to  use.  The  following 
generalized  tasks  will  guide  this  effort: 


(1)  Validate  that  the  equipment  identified  in  the  CCTT  Table  A-l  have 
the  correct  CAGE  Code,  Part  Numbers,  Approved  Item  Names  and 
other  select  acquisitions  data  elements  as  presented  in  the  Federal 
supply  system  AMDEF  data. 


Populate  the  ECDB  with  core  AMDEF  information  after  Table  A-l 
is  validated,  and  using  TRADOC  Weapon  Systems  Names. 
Essentially,  build  the  foundation  to  place  future  data  gathered. 

Create  data  managment  tools  to  rapidily  input  and  edit  the  ECDB 
information  stream.  Then,  create  a  Table  A-l  management  tool  for 
TSM-CATT  and  PM-CATT  to  monitor  and  generate  reports  using 
only  the  ECDB. 

Populate  the  ECDB  with  general  characteristics  information  using 
Technical  Manuals.  Acquire  the  Table  A- 1  IGES  outline  drawings  to 
begin  libraries. 

Schedule  specific  data  population  using  CCTT  software 
development  schedule. 
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ECDB  Points  of 
Contact .... 


The  ECDB  is  not  just  a  software  program,  but  a  team  effort  between 
PM-CATT,  RCI  and  you  the  user.  It  is  this  team  that  will  make  the 
ECDB  a  beneficial  tool.  WE  welcome  you  as  part  of  the  ECDB  team. 
Let  us  know  how  we  can  serve  you.  The  following  is  a  description  of 
each  of  the  team  members. 


•  Program  Manager  for  Combined  Arms  Tactical  Trainers 
(PM-CATT) 

°  Program  Manager  (PM) : 

Colonel  James  Shiflett  is  the  Program  Manager  for  CATT  assigned  by 
Simulation,  Training  and  Instrumentation  Command  (STRICOM). 

°  Assistant  Program  Manager  (APM)  : 

Major  Bill  Johnson  is  the  Assistant  Program  Manager  for  CATT 
assigned  by  STRICOM. 


Mailing  Address : 

PM-CATT 
Suite  100 

305 1  Techonlogy  Parkway 
Orlando,  Florida  32826-3299 

tE&  Phone:  (407)384-3211 
“  Fax: 

DSN :  960-321 1 

B  CCMail :  PM 
APM 

Avon :  PM 
APM 
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Registration  and  Starting  Up  ... 


Starting  ECDB  for 
the  first  time  and 
everytime.... 


This  procedure  will  be  u>ed  even  time  10  start  and  login  into  the  ECDB. 
Please  have  your  password  and  login  codes  available.  If  you  fail  to  have  your 
password  available,  the  ECDB  will  not  be  connected  to  the  PM-CATT  librarv. 
Although  not  connected  to  the  master  library,  the  ECDB  will  default  to  local 
use  and  work  with  onlv  those  files  you  downloaded  or  test  data. 


1  STARTING  . . . 


Double  Click  the  ECDB  icon  to  start  ECDB. 


The  ECDB  for  Window  icon  is 

located  inside  the  PM-CATT  Program 
Group  in  the  Windows  Program 
Manager. 


HBiEl 

Displayed  here  is  a  custom  Program 
Manager  that  has  only  one  Program 
Group.  Your  Program  Manager  and 
Program  Groups  will  appear  different. 


2 

3  Type  your  Login  Code  on  the  Login  Box : 


Program  Manager  -  1 

File  Options  Window  Help 

LOGGING  IN . . . 

Type  your  Password  on  the  Password  Box : 


Decision  Time  for  you 

Failure  to  log  in  will  resuli  in  a 
default  io  using  ECDB  with  local  oi 
test  data. 


Press  Local  for  using  the  ECDB  locally  without  connecting  to  the  PM-CATT 
Library. 

Press  PM-CATT  to  be  linked  to  the  PM-CATT  Library,  or 
Press  Quit  to  exit  ECDB  without  any  connections. 
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Group  000  Table 
Ground  Combat  Vehicles 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

1B000 

n/a 

n/a 

Ground  Comabt  Vehicles  Group  000 

El  AC :  Tanks 

CBS  " 

1B001  *+ 

Ml 

19207:  8750014 

Tank,  Combat,  full-tracked,  105  mm 

1B002  *+# 

M1A1 

19207:  8750015 

Tank,  Combat,  full-tracked,  120  mm 

1B003  *+# 

M1A2 

19207:  8750231 

Tank,  Combat,  full-tracked,  120  mm 

1B004 

M60A1 

192D7:  8750112 

Tank,  Combat,  full-tracked,  105  mm 

1B005 

M60A2 

19207: 

Tank,  Ccmbsn,Ml-tracked,  105  mm 

IB 006  *+ 

M60A3 

19207:  8756945 

Tank,  Combat,  full-tracked,  105  mm 

EIAC  :  Bradley 

1B0OA+ 

M2 

1B018 *# 

M2TOW 

19207: 

Vehicle,  Infantry  Fighting  w 1  TOW 

[MS52267] 

1B012  * 

M2A1 

19207:  8750134 

Vehicle,  Infantry  Fighting 

1B013  * 

M2A2 

19207:  8750175 

Vehicle,  Infantry  Fighting 

1B0OB 

mm 

Vehicle,  Cavalry  Fighting 

1B019  *# 

M3TOW 

I  19207: 

Vehicle,  Infantry  Fighting  w /  TOW 

1B014  * 

M3A1 

19207:  8750135 

Vehicle,  Cavalry  Fighting 

1B015  * 

M3A2 

19207:  8750176 

Vehicle,  Cavalry  Fighting 

1B016  * 

XM 

19207: 

Vehicle,  Cavalry  Fighting  w/  Stinger 

foTP?f»l&TC3R&ll 

Armored  Personnel  Carriers 

1B020  * 

M113A1 

19207:  8736562 

Carrier,  Personnel,  full-tracked,  armored 

1B021  * 

Ml  13A1/TOW 

19207:  10399048 

Carrier,  Guided  missile,  TOW 

1B022  * 

M113A2 

19207:  8750024 

Carrier,  Personnel,  full-tracked,  armored 

[MS52201 ] 

1B023  * 

Ml  13A2/TOW 

19207:  11508962 

Carrier,  Guided  missile,  TOW 

1B024  *+ 

M113A3 

19207:  8750170 

Carrier,  Personnel,  full-tracked,  armored 

1B025  * 

M106A1 

19207:  8736578 

Carrier,  Mortar,  107  mm,  sp,  armored 

1B026  *+ 

M106A2 

19207:  8750026 

Carrier,  Mortar,  107  mm,  sp,  armored 

[MS52199 J 

Legend : 

*  Item  identified  on  Table  A- 1 


+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

1  1  Non- Table  A- 1  Equipments 
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Group  000  Table 
Ground  Combat  Vehicles  (continued) 


Notes 

Mode!  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

EIAC :  APC 

Armored  Personnel  Carriers 

1B027 

M125A1 

19207;  8736579 

Carrier,  Mortar,  81  mm,  sp,  armored 

1B028 

M125A2 

19207;  8750027 

Carrier,  Mortar,  81  mm,  sp,  armored 

1BG29  + 

M577AI 

19207:  8736577 

Carrier,  Command  post,  full-tracked,  armored 

1B030  * 

M577A2 

19207:  8750025 

Carrier,  Command  post,  full-tracked,  armored 

[ MS52198 1 

1B031 

M548 

19207:  8736607 

Carrier,  Cargo,  full-tracked 

1B032  + 

M548A1 

19207;  8750029 

Gamer,  Qugo,  full-tracked 

1B00D  + 

M548A2 

j»BE EHM 

1B033 

M1015A1 

19207: 5051440-1 

Carrier,  Electronic  shelter,  full-tracked 

1B034 

M730 

19207: 8736744 

IB035 

M730AI 

19207;  8750067 

1S036 

19207: 8750132 

Carrier,  Graded  mssile  euipment 

mrnmm 

M74I 

19207;  8736753 

Carrier,  Gun,  anti-air,  Vulcan  20  mm 

1B038 

M741A1 

19207;  8750030 

Carrier,  Gun,  anti-air,  Vulcan  20  mm 

1B039 

M667 

19207;  10160025 

Carrier,  Guided  missile,  Lance 

1B00C 

XM90I 

19207:  8736977 

Combat  Vehicle,  Antitank,  improved,  TOW 

1B040  + 

M901A1 

19207:8750063 

Combat  Vehicle,  Antitank,  improved,  TOW 

1B041  + 

M981 

79207V  8750031 

Combat  Vehicle,  Fire  support  team 

[MS52255] 

M1059 

19207;  8750136 

Carrier,  Smoke  generator  {MS52264 J 

1B043 

M1059E1 

Carrier,  Smoke  generator 

1B044 

19207: 8736888 

1B045 

XM 1101  A3 

Bm 

Carrier,  Smoke  Obcurants  mechanized 

1B046 

OSV/BMP-2 

19207:  n.yd.-2 

1B047 

XM548A3-DS 

19207:  n.y.d>3 

Carrier,  Cargo,  full-tracked  w /  drop  sides 

1B048 

XM548A3-MHC 

19207;  n.y, <1-4 

Carrier,  Cargo;  full-tracked  w 1  mb.  crane 

1B049# 

M1064A3 

Carrier,  Mortar,  120  mm,  sp,  armored 

1B050 

XM-UNTVERSAL 

19207:  n*y>d.-6 

IB051 

XM113A3 

19207;  n.y.d.-7 

Carrier,  Mortar,  120  mm,  sp,  armored 

Legend.; 

*  Item  identified  on  Table  A- 1 


+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

1  1  Non- Table  A- 1  Equipments 
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Group  000  Table 
Ground  Combat  Vehicles  (continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

ELAC :  Guns 

1B062 

M109A2 

Howitzer,  Medium,  self-propelled,  155  mm 

1B063  + 

M 109  A3 

Howitzer,  Medium,  self-propelled,  15S  mm 

1B064 

M109A4 

1B065  *  # 

M109A5 

Howitzer,  Medium,  self-propelled,  155  mm 

1B066  * 

M109A6 

Howitzer,  Medium,  self-propelled,  155  mm 

1B067 

M110A1 

Howitzer,  Heavy^elf-propolled,  8  inch 

[MS52270I 

1B068  + 

M110A2 

Howitzer,  Heavy,  self-propelled,  8  inch 

fMS522511 

1B070  *+ 

M163A1 

19207:  9360800 

1B069 

M163A2 

19207: 12314755 

Carrier,  Valcun 

EIAC :  LAV 

Light  Armor  Vehicle  (LAV) 

IB 090  *+# 

LAV-25 

19207: 

LAV 

1B091  *+# 

LAV-25  TOW 

19207: 

LAV,  TOW  launcher 

1B092  *# 

LAV-25  105 

19207: 

LAV, 

1B093  *# 

LAV-25  MC 

19207: 

LAV,  Mortar  carrier 

1B094  *# 

LAV-25  PC 

19207: 

LAV,  Personnel  carrier 

1B095  *# 

LAV-25  MCC 

19207: 

LAV,  Maintenance  carrier 

■ 

■ 

Lmnd ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

I  1  Non- Table  A- 1  Equipments 
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Group  100  Table 
Tactical  Wheeled  Vehicles 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

IB  100 

Tactical  Wheeled  Vehilces  :  Group  100 

EIAC :  CCOV 

Commercial  Utility  Cargo  Vehicle 

1B101 

- 

19207:  8750075 

Truck,  Cargo 

1B102 

■  ■ 

19207:  8750076 

Truck,  Cargo 

1B103 

- 

19207: 8750077 

Truek,Utilicy 

IB  104 

- 

19207: 8750078 

Truck,  Ambulance 

IB  105 

-  ■ 

wmmumm 

Truck,  Shelter  carrier 

IB  106 

mmmm 

Trade,  Chassis 

IB  107 

19207:  8750131 

Truck,  Shelter  carrier 

EIAC :  GOER 

IB  108 

M520 

19207: 

11614317 

Truck,  Cargo  w/ winch 

IB  109 

M520 

19207: 

11614317-1 

Truck,  Cargo 

1B110 

M553 

19207: 

11614318 

Truck,  Wrecker 

1B111 

M559 

19207: 

11614319 

Truck,  Tanker,  Fuel,  2,500  gallons  w/ winch 

1B112 

M559 

19207: 

11614319-1 

Truck,  Tanker,  Fuel,  2,500  gallons 

1B113 

M877 

19207: 

11614317-3 

Truck,  Cargo,  w/  material  handling  crane 

1B114 

M877 

19207: 

11614317-2 

Truck,  Cargo,  w/  material  handling  crane 

Legend ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

I  1  Non-  Table  A-l  Equipments 
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Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

■ 

Model  Name 

MAC:HEMTT 

1B115  * 

_ 

M977 

1 9207: 

CHEMTTH06 

Truck,  Cargo 

XM977 

19207: 

CHEMTTH01 

Truck,  Cargo 

IB  117  *+ 

XM978 

19207: 

CHEMTTH02 

Truck,  Tanker 

IB  1 18  *+ 

XM978 

19207: 

CHEMTTH07 

Truck,  Tanker 

IB  119 

XM983 

19207: 

CHEMTIH03 

Truck,  Tractor 

IB  120 

M983 

19207: 

CHEMTIH08 

Track,  Tractor 

IB  121 

M983E1 

Unknown  Model 

Track,  Tractor  (No  match  model  number) 

IB  122 

XM984 

19207: 

CHEMTTH04 

Track,  Wrecker 

IB  123  * 

XM984E1 

19207:  XM984E1 

Track,  Wrecker 

IB  124  ♦+ 

M985 

19207: 

CHEMTTH09 

Truck,  Cargo 

IB  125 

M985E1 

Track,  Cargo  (No  matdi  model  number) 

EIAC :  HET70 

I 

1 

I 

IB  126 

M746 

19207:  CPR10201 

m  . 

Htgjh  Mobility  Muht-rrarpose  Wheeled  Vehicle  1 

1B127  * 

M998 

19207:  8750057 

Track,  Utility,  cargo  /troop 

1B128  *+ 

M1038 

19207:  8750058 

Track,  Utility,  cargo 

IB  129  * 

M966 

19207:  8750055 

Track,  Utility,  TOW  carrier 

IB  130 

M1045 

Truck,  tMUty^  TOW  earner 

1B1K1 

M1046 

79207:8750123 

Track,  Utility,  TOW  carrier 

IB  13 1  * 

M1025 

19207:  8750082 

Truck,  Utility,  armament  carrier 

IB 1 32  * 

M1026 

19207:  8750083 

Truck,  Utility,  armament  carrier 

Legend; 


*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  I 

I  1  Non-  Table  A-l  Equipments 
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Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC :  HMMWV 

Blue  Force  Equipments  Master  Index  List 

High  Mobility  Multi-purpose  Wheeled  Vehicle  1 

IB  133  *#+ 

M1043 

19207:  8750121 

Truck,  Utility,  armament  carrier  w/Mkl9 

IB  134  *#+ 

Ml  044 

19207:  8750122 

Truck,  Utility,  armament  carrier  w/ M2  .50 

IB  135  * 

M1037 

19207:  8750117 

Truck,  Utility,  S-250  shelter  carrier 

1B136  * 

M1042 

19207:  8750124 

Truck,  Utility,  S-250  shelter  carrier 

1B137 

M996 

19207:8150060 

Track,  Ambulance 

1B138 

M997 

19207:  8750059 

Truck,  Ambulance 

1B139 

M1035 

19207: 87501 16 

Truck,  Ambulance 

Note  :  No  HMMWV  Model  numbers  have  been  lisited  with  DLSC 


EIAC :  MAN 

MA.N  Vehicle  System 

IB  140 

M1001 

D3273: 

81991288916 

Track,  Tractor 

1B141 

M1002 

D3273: 

81991288918  f 

Track,  Tractor 

IB  142 

M1013 

D3273: 

81991288917 

Truck,  Tractor 

1B143 

M1014 

D3273: 

81991288919 

Truck,  Tractor 

Note  :  This  El  AC  series  is  built  by  MAN  Nutifahzeuge  GMBH ,  Germany. 


EIAC:  M35 

Truck «  2  3/2  Ton,  6  x  6 

1B1K2  * 

M35A1 

19207:  8736236 

Truck,  Cargo 

1B1K3  * 

M35A1 

19207:  8736237 

Truck,  Cargo  w/  winch 

1B144  * 

M35A2 

19207:  8736581 

Truck,  Cargo 

1B145  * 

M35A2 

19207:  8736582 

Truck,  Cargo  w/  winch 

IB  146  * 

M35A2C 

19207:  8736733 

Truck,  Cargo 

IB  147  * 

M35A2C 

19207:  8736735 

Truck,  Cargo  w/  winch 

IB  148  * 

M35E8 

2320-00-542-5635 

Truck,  Cargo  (No  match  Model  No  or  NSN) 

1B149 

M36A2 

19207: 8736592 

Legend ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

_  Non-  Table  A- 1  Equipments 


as  of  23  November,  1993 
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I 


ECDB  Master  Index 


Blue 

Forces 

L/isf 


Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

E1AC:  M35 

IB  150 

M36A2 

19207: 8736593 

Track,  Cargo  w/winch 

IB  154 

M36A2C 

79207:8736836 

Trade,  Chassis 

1B1K5 

M44AI 

79207:8736440 

Truck,  Cargo 

1B151 

M44A1 

79207: 8736470 

1B152 

M44A2 

19207: 8736576 

Trade,  Chassis  '  '' 

1B153 

M44A2 

79207:8736594 

IB  155 

M45A2 

79207:8736574 

Chassis,  Truck 

IB  156 

M45A2 

79207:8736575 

Chassis,  Track  w/winch 

IB  157 

M46A2 

79207:8736595 

Chassis,  Track 

IB  158 

M46A2C 

19207: 8736573 

Chassis,  Truck 

IB  159 

M46A2C 

2320-00-077-I630 

Chassis,  Trade 

IB  160 

M49A1C 

1B1K4 

M49A1C 

79207:8736352 

Trade,  Tanker,  fad  u/wosck 

1B161 

M49A2C 

79207: 8736567 

Track,  Tanker 

IB  162 

M49A2C 

79207: 8736566 

Trade,  Taiiker,  fuel,  1200  gals.  W&incfc  ■ 

1B1K7 

M50A1 

Trade,  Tanker,  water  w/winch 

1BI63 

M50A2 

79207:8736355 

Trade,  Tanker.wafer,  1000  gab. 

1B164 

M50A2 

19207: 8736568 

Truck,  Tank 

IB  IKS 

M50A2 

79207:8736596 

Truck,  Tanker,  water,  1000  gals. 

1B165J 

MS0A3 

IB  166 

M50A3 

Track,  Tank  w/winch 

Legend 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

I  Non-  Table  A-l  Equipments 


as  of  23  November,  1993 


490 


c;.-v  n 


ECDB  Master  Index . 


Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:  M35 

Blue  Force  Equipments  Master  1 

Truck  ,  2 1/2  Ton,  6x6 

IB  167 

M109A1 

79207:8736281 

Truck,  Van  w/ winch 

IB  168 

M109A1 

79207:8736274 

Truck,  Van,  shop 

IB  169 

M109A2 

19207: 8736357 

Truck,  Van,  shop 

M109A2 

19207: 8736356 

Track,  Van  w/winch 

1B171 

M109A3 

79207:8736569 

Truck,  Van 

IB  172 

M109A3 

79207:8736570 

Truck,  Van  w/winch 

1B173 

M185A1 

79207:8736466 

1B174 

M185A2 

79207:8736467 

Track,  Shop,  instrument  repair 

IB  175 

M185A2 

49404)0987*8800 

Truck,  Shop,  instrument  repair 

IB  176 

M185A3 

EiilSSlil 

Truck,  Shop,  instrument  repair 

1B1K9 

M185A9 

79207:8736588 

Track,  Repair  Shop  w/wrncA 

1B1K0 

M27SA1 

79207;  8736359 

Torek;  Tractor 

1B177 

M275A2 

79207:8736571 

Truck,  Tractor 

1BI78 

M275A2 

79207:8736597 

IB  179 

M292A2 

Track,  Van,  expansible 

1B180 

M292A3 

79207:  8736653 

Track,  Van,  expansible 

1B1L3 

M292A4 

79207:8736654 

Truck,  Van,  expansible 

IB  181 

M292A5 

79207:8736655 

Track,  Van,  expanable 

IB  182 

M342A2 

79207:8736598 

1B1L4 

M342A2 

79207:8736589 

*i .  nn  i  mi 

IB  183 

M602 

79207:8736378 

Truck,  Cargo 

1BIL5 

M602 

79207:8736134 

Track,  Cargo 

1B184 

M607 

Unknown  Model 

Track,  Tractor  2320*00-695^9457 

IB185 

mmwmm 

1B1L6 

M609A1 

79207:8736659 

Truck,  Van 

1B1L7 

M6I0 

79207: 8736648 

Track,  Tanker,  walin' 

IB  186 

M610 

29207:8736474 

Trade,  Tanker,  water,  1000  gals. 

Legend ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

I  Non-Table  A- 1  Equipments 


as  of  23  November,  1993 
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ECDB  Master  Index 


Blue 

Forces 

Fist 


Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:  M35 

Blue  Force  Equipments  Master  Index  List 

Truck ,  2 1/2  Ton,  6x6 

1B1L8 

M611C 

19207: 8736476 : 

Trade,  Tanker;  gasoline,  1000  gals. 

18187 

M611C 

19207:8736650 

Trade,  Tanker,  gasoline,  1200 gals. 

IB  188 

M613 

19207:8736638 

Trade,  Shop,  instrument  repair 

IB  189 

M614 

19207:8736656 

Trade,  Dump  i—v 

1BJL9 

1 

19207:8736657 

Track,  Dump  w/ winch 

IBIZA 

M615  *♦ 

19207:8736688 

Trade,  Ambulance 

1B1ZB 

mm** 

19207:8736641 

Chassis,  Tradk  W  winch 

1B1ZC 

mm** 

19207:8736669 

Chassis,  Trade 

M617** 

Chassis,  Track 

IB1ZB 

mm** 

Chassis,  Track  .  ■  '  ■  .  ■ 

1B1ZF 

M619  ** 

19207:213666$ 

Chassis,  Truck 

1B1ZG 

M619  ** 

1Z1ZH 

M620  ** 

Chassis,  Thick 

Truck,  Cargo 

IB  191 

i 

i 

>34, 

m 

is 

IB  192 

M623 

1B193 

M624  :f>' 

Trade,  Dump 

lBIZt 

19207:8736847 

Tractor,  Truck 

1B1ZJ 

M656** 

Tractor,  Cargo 

M656  ♦* 

19207:8736751 

Tractor,  Cargo  w/winch 

1B1ZL 

M748A1  *♦ 

Tractor,  Bolster 

M748E2** 

Tractor,  Bolster  w/winch 

1B194 

M751A2 

hb 

IB  195 

M756A2 

19207:8736769 

Trade,  Pipeline  construction 

M763  • 

1 

1 

* 

t! 

£ 

ft 

M764 

« 

1 

£ 

m 

wmmm 

WMMMEm 

IB  198 

V18A1MTQ 

19207:  V18AMTQ 

Trade,  Maintenance 

Legend : 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

**  Model  Number  requires  validation  if  in  M35  Series  of  trucks 

I  I  Non-  Table  A-l  Equipments 


as  of  23  November,  1993 
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Blue 

Forces 

List 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:  M39 

Blue  Force  Equipments  Master  Index  List 

Trade ,  5  Ton  ;; .  ■ . 

IB  199 

M51A1 

1 9207:  8736449 

Truck,  Dump 

1B11A 

M51A1 

79207:8736448 

Truck,  Dump  w/winch 

IBT1B 

M51A2 

29207:8736516 

Track,  Dump  w/winch 

1B11C 

M51A2 

29207:8736517 

Track,  Dump 

M51A2 

19207:  M51A2 

1B11D 

M52A1 

29207:8736432 

Track,  Tractor 

1B1LB 

M52AI 

19207:  8736433 

Track,  Trader  w/winch 

1B11E 

M52A2 

29207:8736519 

1BI1F 

M52A2  ; 

29207:  M52A2 

Track,  Tractor 

1B11G 

M52A2 

29207:8736518 

Truck,  Tractor  w/winch 

1B11H 

M54A2 

29207:8736520 

Track,  Tractor 

1B11I 

M54A2 

29207:8736521 

Truck,  Tractor 

1B113 

M54A2C 

29207:  8736734 

Track,  Cargo  w/winch 

1B11K 

M54A2C 

29207:8736732 

Track,  Cargo 

1B11L 

Track,  Cargo  w/winch 

1B1LC 

M59 

1BILD 

lfillM 

M61A2 

232CNJG-965-0321 

1B11N 

M61A2 

2320-00-055-9264 

Chassis,  Truck  (No  match  Model  No  or  NSN) 

ib  no 

2320^0-285-3757 

Cbassis,  Track  (No  match  Modd  No  orNSN) 

1B11P 

2320-00-226-6251 

Chassis,  Trade  (No  match  Model  No  or  NSN) 

1B110 

M63A2C 

IB  HR 

M246A2 

Track,  Tractor  w/winch 

1B11S 

M291A1 

29207: 8736842 

1BI1T 

M29IA1C 

19207:8736843 

Track,  Van 

1B11U 

S 

2 

►3 

mo7:  mom 

Track,  Van 

Legend; 

*  Item  identified  on  Table  A- 1 

+  Identified  a s  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

1  1  Non-  Table  A-l  Equipments 
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ECDB  Master  Index. 


Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 
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o.-vn' 


ECDB  Master  Index. 


Hint' 

Forces 

Fiat 


Group  100  Table 

Tactical  Wheeled  Vehicles  ( Continued) 


Notes  Model  Number 


Part  Number 


1B1A1 


1B1A3 


1B1A4 


1B1A5 


EIAC:  M39 


M291A2 


M291A2C 


M291A2D 


M328A1 


M328A2 


M543A1 


19207:  8736692 


19207: 8736693 


19207:  $736694 


19207:  mms 


mommmn 


19207:9136465 


Truck ,  5  Ton 


Truck,  Van 


Truck,  Van 


Truck,  Van 


Truck,  Stake 


Model  Name 


ts 


ex  List 


Truck,  Wrecker 


o  match  Mode)  No  or 


1BUX  i 

M543A2 

19207:  8736537 

[>Triiik,  Wredcer  w/winch 

1B11Y 

M748A1 

19207:  mom 

,  Bolster  w/winch 

IB11Z  I 

M748E2 

19207.9136150 

|  Ttbck,Bolls«»r  w/windi 

EIAOM123 


. . . 


29207:8736634 


MJ31A1 

79207:8736678 

M151A1C 

|  29207:  8736677 

IBM— 

19207:  mms 

[M718A1 

29207:8736906 

EIAC:  M561 


M561 


92 


EIAC:M656 


29207:87364074 


19207:  8736827 


Ibid.  18 Ton,  6x6 


Truck,  Tractor  w/winch 


Track,  l/4Ton,4x4 


Truck,  U 


.  Ambulance,  Frontline 


^Ambulance,  Frontline 


'.TfcMidk- :v  ■  ' 


Truck,  Cargo 


Ambulance 


mmm&mms 

Wm: 

Wm: 

29207:8736751  1 

1B1B3 


Legend : 
* 

+ 

# 

E=l 


XM757 


XM757 


XM791 


mm 


mmmmm 


19207:  mom 


79207: 8736825 ; 


TruckrTiactor 


Tractor 


Item  identified  on  Table  A-l 

Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 
TSM  Priority  of  1 
Non- Table  A-l  Equipments 


as  of  23  November,  1993 
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ECDB  Master  Index 


Blue 

Forces 

Ltisi 


Group  100  Table 

Tactical  Wheeled  Vehicles  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

ElAC:  M809 

1B1F2 

M809 

19207: 8736849 

Chassis 

1B1F3 

M809 

19207:  8736850 

Chassis 

1B1F4 

M809A1 

15207:8736856 

Chassis 

1B1F5 

M810 

19207:8736858 

Chassis 

1B1F6 

XM810 

19207:  8736859 

Chassis 

1B1F7 

M811 

75207:8736864 

Chassis 

1B1F8 

M8H 

19207: 8736865 

Chassis 

1B1F9 

19207:  8736868 

Oiassis 

1BIF0 

EHE— 

19207:  8736870 

Chassis  : : 

1B1G1 . Iti 

M812 

19207:  8736874 

Chassis 

1BIG2 

M812A1 

19207: 8736876 

Chassis 

M813 

19207: 8736851 

Truck,  Cargo 

M813 

79207:8736852 

Truck,  Cargo 

IB  I  LF 

M8I3A1 

75207:8736853 

Truck,  cargo,  dropside  w/ winch 

1B1LG 

M813A1 

19207:8736854 

1B1LH 

M814 

EgCT 

Truck,  Cargo 

1B1G4 

M814 

19207:8736867 

Truck,  Cargo 

1B1G5 

M815 

75207: 8736855 

Truck,  Bolster  w/winch  fMS52187J 

1B1G6 

M816 

79207:8736857 

Truck,  Work  fMS5218Bl 

1B1G7 

19207:8736860 

1B1GS 

M8I7 

1B1G9 

i Mussm 

Truck,  Tractor  [MS52190J 

1B1G0 

M818 

19207:8736863 

Truck,  Tractor  JMS521901 

1B1H1 

M819 

19207: 8736869 

Truck,  Tractor,  wrecker  w/  winch 

fMS521911 

1B1H2 

M820 

19207:8736871 

1B1H3 

M820A1 

19207;  8736872 

'lBtH4iilll 

M820A2 

79207:8736873 

Truck,  Van,  expansible 

1B1H5 

M821 

79207:8736875 

Truck,  Stock  Bra,  transporter 

Legend.; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

1  Non- Table  A- 1  Equipments 

as  of  23  November,  1993 
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ECDB  Master  Index 


Blue 

Forces 

List 


Group  100  Table 

Tactical  Wheeled  Vehicles  (  Continued) 


Notes 

Model  Number 

Part  Number 

Mode!  Name 

EIAC:  M876 

Blue  Force  Equipments  Master  Index  List 

Truck 

1B1B4 

XM876 

19207: 

XM976TACOM 

Truck*  Maintenance  telephone  w/  winch 

EIAC:  M880 

Truck  '  .  • 

1B1B5 

XM880 

19207: 8736960 

Truck,  Cargo 

1BIB6 

XM881 

19207: 8736960-1 

Truck,  Cargo 

1B1B7 

■mmm 

Truck,  Cargo 

1B1B8 

XM883 

19207: 8736960-3 

Truck,  Cargo 

1B1B9 

XM884 

Truck,  Cargo 

1BIC0 

XM885 

Truck,  Cargo . Ill1 

1BIC1 

XM886 

Trudc,  Ambulance 

XM887 

Chassis 

1B1C3  1 

Truck,  Telephone  Maintenance 

1B1L1 

XM889  ** 

Truck,  Cargo 

1B1C4 

XM890 

Truck,  Cargo 

1B1C5 

XM89I 

!9207:m696Ul 

Track,  Cargo 

1B1C6 

XM892 

19207: 8736961*2 

Truck,  Cargo 

1B1C7 

XM893 

19207: 8736963 

Truck,  Ambulance 

EIAC:  M915 

Tuck  ■ 

1B1C9 

XM9I5 

19207:  XM91S 

Track,  line  haul  tractor  IMS522021 

IB  ICO  :  ■ 

XM916  .  . 

19207:  XM916 

XM917 

Truck,  Dump,  20  Ton 

1B1D2 

XM918 

lliliHI 

Distributor,  Bitomimous  material 

1B1D3  | 

19207: 

XM9I9CHASSIS 

Tuck,  Concrete  mobile 

1B1D4 

M920 

/9207;XM92O 

?.Lv*  \m  uuS^iljUaMi 

Legend ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

1  1  Non-  Table  A-l  Equipments 


as  of  23  November,  1993 
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1  c:/vr  i~ 


ECDB  Master  Index 


BJur 

Forces 

Fist 


Group  100  Table 

Tactical  Wheeled  Vehicles  (  Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:M915A1 

1B1D5 

M915A1 

19207:  M915A1 

Truck,  Line  haul  tractor 

EIAC:  M939 

Truck 

1B1D6 

M923 

19207:  8736986-2 

Track,  Cargo 

M923 

34623:  M923 

mmm  r  m  lilt  n  i  m 

1B1D7  * 

M925 

19207:  8736986-1 

Truck,  Cargo 

M925 

34623:  M925 

Truck,  Cargo 

1B1D8 

M927 

W^SBSJB3k 

1B1D9 

M928 

19207: 8736987-1 

Track.  Cargo,  XLWB 

IB  IDO 

M929 

19207: 8736989-2 

Trade,  Dump 

IBiEl 

M930 

19207:  8736989-1 

Trade,  Dump 

1B1E2 

M931 

19207: 8736990-2 

Track,  Tractor 

EIAC:  M939 

Truck  ' 

1B1E3 

M932 

19207: 

Track,  Tractor 

M932 

34623:14932 

Track,  Tractor 

iliMMI 

mssssm m 

1B1E5 

19207: 8736992 

Trade;  Van;  expansible 

1B1E6 

M935 

19207:  mem 

Trade,  Van,  expansible,  WHLG 

1B1E7  * 

M936 

19207:  8736998 

Truck,  Wrecker 

* 

M936 

34623:  M936 

Truck,  Wrecker 

1B1E8 

MHH 

No  part  number 
and  to  be 
yiiiindbiit&EnaiiMl : 

Track,  5  Ton.  PEP  23204)1-048-2450 

1B1E9 

M940 

No  part  number 
and  to  be 
discontinued 

Track,  Chassis  2320-01-047-8743 

1B1E0 

M94I 

Unknown  Model 

Track.  Chassis  2320-01-048-8742 

1B1F1 

M945 

ism 

Truck,  Chassis  w/ winch 

Legend ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

_ _ _]  Non- Table  A- 1  Equipments 


as  of  23  November,  1993 
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ECDB  Master  Index 


Blue 

Forces 

Fiat 


Group  200  Table 
Combat  Engineering  Vehicles 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Maste 

1B200 

Combat  Engineering  Vehicles  :  Group  200 

EIAC:  ACE 

Track  v  Heavy  Eouiimieiit,Gainineritil 

1B2B1  *+= 

M9 

19207:  8750001 

Bulldozer,  Earthmover,  armored  combat 

[MS52271 1 

1B2B2  * 

D7F 

D7F 

Bulldozer,  Erathmover 

EIAC:  ARV 

Armored  Recovery/  Engineering  Vehicles 

1B202  * 

M88A1 

19207:  8736888 

Armored  Recovery  Vehicle,  lull-tracked 

1B203  * 

M88A2 

19207: 

Armored  Recovery  Vehicle,  full-tracked 

IB 204  *+= 

M728 

19207:  8750112 

Combat  Engineering  Vehicle,  full-tracked 

1B205  * 

BAT-2 

19207: 

RTE  Gearing  Vehicle 

1B206  * 

MTK-2 

19207: 

Mine  Clearer 

1B207  * 

PMR-3 

19207: 

Mine  Layer 

1B208  * 

M93 

19207: 

WBC  Recon.  Vehicle 

EIAC:  CEASS 

Comlwtlmdmsuing  Accessories 

1B2A1  * 

MT-5K 

19207: 

Roller  /Plow 

1B2A2* 

KMT-4/6 

Mine  Plow 

S) 

%1  % 

EIAC:  A  VLB 

Annozed  Bridges 

W  1B2&4  *+# 

MT-20 

19207:  8892020 

Armored  Vehicle  Launched  Bridge 

Rf'juMm 

MT-55 

Bridge 

wMzmm 

EIAC-.TRAILR 

Shelter 

IB2AT* 

M-105 

19207: 

Shelter 

$ 


Lteendi 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

1  |  Non- Table  A- 1  Equipments 


as  of  23  November,  1993 
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ECDB  Master  Index. 


JiJur 

Forces 

Lris( 


Group  300  Table 
Aircraft  Systems  (All  types) 


Notes 


Model  Number 


Part  Number 


Model  Name 


1B301  *+= 


1B302  * 


1B303  * 


1B304  *+= 


1B305  * 


1B306  *+= 


1B307  * 


1B308  *+ 


1B309  *+ 


1B310  *+ 


EIAC:  Rotor 


AH-1S 


AH-1P 


AH-1G 


AH-64A 


CH-47 


OH-58D 


RAH-66 


UH-1H 


UH-60A 


UH-60L 


1B360  * 


1B361  *+= 


1B362  *+ 


1B363  *+ 


1B364  * 


1B365  * 


1B366  *+ 


1B368  * 


1B367  * 


1B369  *+ 


Legend  ; 


Blue Force  Eq 


ter  Index 


Aircraft  Systems  :  Group  300 


KotoryAircaft 


Attack  Helicopter,  Cobra 


Attack  Helicpoter,  Cobra 


Attack  Helicopter,  Cobra 


Attck  Helicopter,  Apache 


Transport  Helicpoter,  Medium  lift,  Chinook 


Scout  Helicopter,  Kiowa  Warrior 


Utility  Helicopter,  Hue 


Utility  Helicopter,  Hue 


Transport  Helicopter,  Blackhawk 


Transport  Helicopter,  Blackhawk 


Axed  Wing  Ainalt 


Harrier 


Corsait 


Wartho 


Phantom 


# 

CZJ 


Item  identified  on  Table  A-l 

Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 
TSM  Priority  of  1 
Non-  Table  A-l  Equipments 


as  of  23  November,  1993 
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499 


[OATT 


ECDB  Master  Index 


Blue 

Forces 

List 


Group  400  Table 
Guide  Missile  Systems  (all  types) 


Notes 

Model  Number 

Part  Number 

Mode!  Name 

1B400 


Guided  Missile  Systems  :  Group  400 


EIAC:  GMS 

1B401  * 

M48A2 

1440-01-106-3089 

GMS,  Intercept-aerial,  carrier-mounted 

1B402  * 

M48A2E1 

GMS,  Intercept-aerial,  carrier-mounted 

1B403  * 

M48A3 

GMS,  Intercept-aerial,  carrier-mounted 

1B404  * 

STINGER 

Air  Defense  System,  Manportable 

1B405  * 

M270 

Mutliple  Rocket  Launchers  (MLRS) 

EIACtMan-GMS 

Manportable  Guided  Missite  System 

1B430  * 

MANPADS 

Air  Defense  System,  Manportable 

1B431  * 

M136  (AT-4: 

Launcher,  Heat,  84  mm 

1B432  * 

DRAGON  2 

Assault  Weapon  System,  Medium ,  M47 

1B433  * 

JAVELIN 

Advanced  Anti-Tank  Weapon  System,  Medium 

1B434  * 

TOW-2A 

1B435  * 

TOW-2B 

1B436  * 

HELLFIRE 

1B437 * 

AVENGER 

HMMWV,  Pedestal-mounted,  Stinger 

1B438 

EIAC:  GMS 

GuldedMissikSyseins,  Airborne 

1B4A1  * 

ATM-9 

1440-01-106-3089 

Sidewinder 

1B4A2  * 

ATM-21 

Sparrow 

1B4A3  * 

M48A3 

Rocket,  2.75  inch 

1B4A4* 

STINGER 

Rocket,  5  inch 

1B4A5* 

M270 

Rocket,  120  mm 

1B4A6  ♦ 

M26 

Rocket,  270  mm  tactical  w/  M77  warhead 

1B4A7  * 

M26 

Rocket,  270  mm  tactical  w/  TGW  warhead 

1B4A8  * 

M26 

Rocket,  270  mm  tactical  w/  SADARM 
warhead 

1B4A9  * 

M26 

Rocket,  270  mm  tactical  w/  AT2  warhead 

1B4A0  * 

Rocket,  Volcano 

Legend ; 


*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  TSM  Priority  of  1 

'H  Non-  Table  A-l  Equipments 


as  of  23  November,  1993 
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500 


5^ 

«.  Nil 


ECD5  Master  Index 


/>’/.«■ 
f1  orccs 

List 


Group  500  Table 

Communications  Systems  and  Equipments 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

IB500 

Communication  Systems  :  Group  500 

EIAC:  Comm 

Communications  Systems  and  Equipment 

IB50I 

AN/GRC125 

80063:  PPL- 1887 

RADIO  SET,  AN/GRC-125 

IB502 

AN/GRC160 

80058: 

ANGRC160 

RADIO  SET,  AN/GRC-160 

1B503 

AN/VDR-1 

80058: 

AN/VDR-1 

RADIOLOGICAL  WARNING  DEVICE, 
AN/VDR-1 

IB504 

AN/VRC-87C 

80063: 

A3141516-1 

RADIO  SET,  AN/VRC-87C 

IB505 

AN/ VIC- 1  V 

80058: 

ANVlCl(v) 

INTERCOMMUNICATIONS  SET, 
AN/VIC-1(V) 

1B506 

AN/VRC-53 

80063:  PPL- 1886 

RADIO  SET,  AN/VRC-53 

IB507 

AN/VRC-64 

80058: 

ANVRC64 

RADIO  SET,  AN/VRC-64 

IB508 

AN/VRC-87A 

80063: 

A3080227-1 

RADIO  SET,  AN/VRC-87A 

IB509 

AN/VRC-88A 

80063: 

A3080228-1 

RADIO  SET,  AN/VRC-88A 

B510 

AN/VRC-89A 

80063: 

A3080229-1 

RADIO  SET,  AN/VRC-89A  S  \'ncCrf\e<, 

B511 

AN/VRC-90A 

80063: 

A3080230-1 

RADIO  SET,  AN/VRC-90A  S  .  n  c 

B512 

AN/VRC-91A 

80063: 

A3080231-1 

RADIO  SET,  AN/VRC-9 1 A 

B513 

AN/VRC-92A 

80063: 

A3080232-1 

RADIO  SET,  AN/VRC-92A  5  l«c**c* 

B514 

AN/PRC  1 19A 

80063: 

A3080226-1 

RADIO  SET,  AN/PRC- 119A 

B515 

AS1729/VRC 

$0065:  SM-D- 
542001 

ANTENNA,  AS-1729/VRC 

B516 

AS27319GRC 

80058:  AS- 
2371 9(  )/GRC 

ANTENNA  ASSEMBLY,  Whip 
AS-27319()/GRC 

B517 

OA3633/GRC 

80063:  SM-D- 
454880 

AMPLIFIER-POWER  SUPPLY  GROUP; 
OA-3633/GRC 

fc7-i523C O/o  152,5  tc)/ u  5 


15  of  25  January,  1994 
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ECDS  Master  Index 


f'orccs 

Ijisi 


Group  600  Table 
Mortars  and  Grenade  Launchers 


Notes  Model  Number  v  I  Part  Number 


Model  Name 


BlueForce  Equipments  Master  Index: last 


Mortars  &  Grenande  Launchers 
Group  300 


Mortars 


19204 :  8401840  |  Mortar,  4.2  inch 


|  1  Non- Tabic  A- 1  Equipments 

as  of  23  November,  1993 


r  ^ 

*  \  r  r 


ECD8  Master  index 


*  ttrt  ( 


Group  700  Table 

Machine  Guns,  Weapons  and  Rifles 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Foixe  Equipments  Master  Index  Lrist 

1B700 

Machine  Guns,  weapons  &  rifles  : 

Group  700 

EIAC:  MG 

- 

Machine  Guns  (MG)  all  types 

1B701 * 

Mk.  19  Mod.3 

10001 : 3269419 

MG,  Caliber,  40  mm 

1B702 * 

M2 

19204  :  8401485 

MG,  Caliber  .50;  Browning  flexible,  w/e 

IB703 * 

M2 

19204  :  5910630 

MG,  Caliber  .50;  Browning  M48  turret  type 

1B704* 

M60 

19204  :  7269100 

MG,  Cailber,  7.62  mm 

1B705  * 

M73 

1005-00-869-8816 

1B706 * 

M73A1 

1005-00-937-7323 

1B707  * 

M219 

1005-00-077-2354 

MG,  Caliber,  7.62  mm 

1B708  * 

M249 

19207  :  9348199 

Machine  Gun,  5.56  mm  w/  equipment 

1B709 

M249 

§^mi 

Machine  Gun,  5.56  mm  (SAW) 

(Not  Procureable-  Use  9348199) 

Sio 

I&7I1  rftbOV  MCr,  7.C 

EIAC:  Rifles 

1B750  * 

M16 

19204  :  8448600 

Rifle,  5.56  mm 

1B751  * 

M16A1 

1005-00-073-9421 

Rifle,  5.56  mm 

1B752 * 

M16A2 

Rifle,  5.56  mm 

750  751  & 
752 

1005-00-921-5004 

Magazine,  Cartridge,  30  round 

705  751  & 
752 

1005-00-165-4336 

Sling,  small  arms 

I 

I 

I 


EIAC:  Weapon 


Hand  held  weapons  all  types 


Legend  : 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

2 _  TSM  Priority  of  I 

_ i  Non- Table  A- 1  Equipments 


os  of  23  November,  1993 
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503 


ECDS  t.lis'i-jr  Index 


/' Hr rex 
List 


Group  S00  Table 
Mines  and  Grenades 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

1B800 

Mines  &  Hand  Grenande : 

Group  800 

EIAC;  Mines 

MiiiesMitypes  :i 

1B801  ♦ 

BarMine 

Mine,  Antitank 

1B802  * 

M19 

Mine,  Antitank 

;Ay.wv.y.VAV.*.vAv.v//Av,‘.-.v.v^WiWW/Mv.v 

EIAC:  GL  III 

Grenade  Launchers  all  types 

1B880 * 

M203 

19204  :  8448300 

Grenade  Launcher,  40  mm 

1B881 * 

M79 

19204 : 

Grenade  Launcher,  40  mm 

— 

_ 

Hand  &  Rifle  Greoadesall  types 

1B8A0-  V',„- 

.  -mm 
.  mm 

l|j8 

1B8A1 

* 

|§|J| 

1B8A2  * 

AN-M8 

79205;  13-19-32 

Grenade,  Hand;  smoke 

LCC-A,  AMCTC  3408 
(DoDAC :  1330-G900) 

1B8A3 

AN-M14r 

iill-  'vi*. 

-  '  t; 

*  J&w  H  -  i 

1B8A4  * 

L8A1 

19203 : 

TW74GF 

Grenade,  Launcher,  smoke :  screening,  RP 
LCC-A  (DoDAC  :1330-G815) 

1B8A5 * 

L8A3 

79203 : 
D13-19-100 

Grenade,  Launcher,  smoke :  screening,  RP 
LCC-A  (DoDAC  :1330-G8 15) 

1B8A6  :j 

MkT  .  ;.r: 

79203  V  $44573 

Grenade,  Hand;  illuminating 

Obselete 

(DoDAC :  1330-G895) 

Legend  ; 

•  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

f _  TSM  Priority  of  1 

_  Non- Table  A- 1  Equipments 


as  of  23  November,  1993 


21 
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ECDii  '.‘.is ter  InJi1 > 


Js/rsf 

r  • 

f*  4»  rt  t'  • 
1  ^tst 


Group  800  Table 
Mines  and  Grenades  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:  HG 

Blue  Force  Equipments  Master  Index  List 

Hand  &  Rifle  Grenades  all  types 

1B8A7 

MklAl 

19203  :  82-1-7 

Grenade,  Hand;  illuminating 
;  Obselete  MSR 11756003 

1B8A8 

Mk  2  ^ 

19203  ?  82-0-143 

' :  TrWJ*??-;?**-' x>x>x>  • : -  - 

1B8A9 

mm :  92  J 5459 

|  V  %  m 

1B8AA* 

M7 

79203 :  13-21-3 

Grenade,  Hand;  smoke,  wp 

MSR:  8746046  (DoDAC  :1330-G960) 

1B8AB  * 

M7A1 

19203 :  13-21-7 

Grenade,  Hand;  smoke,  wp 

MSR:  8746046  (DoDAC  :1330-G960) 

1B8AG 

-x  x- :•  x->X:Xv 

'  ■ 

-i'  ,  i " 

BBlli 

fii  1 

1B8AD  * 

M15 

19203: 13-19-18 

Grenade,  Hand;  smoke 

MSR:  11756003  (DoDAC  :1330-G935) 

1B8AE  * 

M19A1 

19203  :  82-0-109 

Grenade,  Rifle;  smoke,  wp 

MSR:  11756003  (DoDAC  :1330-H030) 

1B8AF  * 

M22 

99999: 

1330-G995 

Grenade,  Rifle;  smoke,  green,  impact 

MSR:  11756003  (DoDAC  :1330-G995) 

IB8AG  * 

M22 

99999: 

1330-H010 

Grenade,  Rifle;  smoke,  red,  impact 

MSR:  11756003  (DoDAC  .1330-H0 10) 

1B8.AH  * 

M22 

99999: 

1330-H020 

Grenade,  Rifle;  smoke,  violet,  impact 

MSR:  11756003  (DoDAC  :1330-H020) 

1B8AI  * 

M22A2 

99999: 

1330-H035 

Grenade,  Rifle;  smoke,  yellow,  impact 

MSR:  1 1756003  (DoDAC  :  1330-H035) 

1B8AJ  * 

M22A2 

99999 : 

1330-G995 

Grenade,  Rifle;  smoke,  green,  impact 

MSR:  11756003  (DoDAC  :  1 330-G995) 

Legend  : 

*  Item  identified  on  Table  A-l  for  smoke  munitions 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

£ _  TSM  Priority  of  I 

I  Non- Table  A-l  Equipments 


os  of  23  November,  1993 


22 
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ECDB  Master  In  Jet 


/ 4  times 

Lis,: 


ft, 

«  \  l  I  , 


Group  800  Table 
Mines  and  Grenades  ( Continued ) 


Notes 

Model  Number 

Part  Number 

Model  Name 

• -  v | 

sEIAC:  H6  -  -  . 

1B8AK  * 

M22A2 

99999: 

1330-H010 

Grenade,  Rifle;  smoke,  red,  impact 

MSR:  11756003  (DoDAC  :1330-H010) 

1BSAL  * 

M22A2 

99999: 

1330-H020 

Grenade,  Rifle;  smoke,  violet,  impact 

MSR:  11756003  (DoDAC  :1330-H020) 

IB8AM* 

M22A2 

99999: 

1330-H035 

Grenade,  Rifle;  smoke,  yellow,  impact 

MSR:  11756003  (DoDAC  :1330-H035) 

1B8AN  * 

M23 

99999: 

133O-H000 

Grenade,  Rifle;  smoke,  green,  impact 

MSR:  11756003  (DoDAC  :1330-H000) 

M23 

99999: 

1330-H015 

Grenade,  Rifle;  smoke,  red,  impact 

MSR:  11756003  (DoDAC  :1330-H015) 

1B8AP  * 

M23 

99999 : 

1330-H025 

Grenade,  Rifle;  smoke,  violet,  impact 

MSR:  11756003  (DoDAC  :1330-H025) 

1B8AQ  * 

M23 

99999: 

1330-H040 

Grenade,  Rifle;  smoke,  yellow,  impact 

MSR:  11756003  (DoDAC  .T330-H040) 

1B8AR  * 

M23A1 

99999: 

1330-H000 

Grenade,  Rifle;  smoke,  green,  impact 

MSR:  11756003  (DoDAC  :1330-H000) 

1B8AS  * 

M23A1 

99999: 

1330-H015 

Grenade,  Rifle;  smoke,  red,  impact 

MSR:  11756003  (DoDAC  :1330-H015) 

1B8AT  * 

M23A1 

99999: 

1330-H025 

Grenade,  Rifle;  smoke,  violet,  impact 

MSR:  11756003  (DoDAC  :1330-H025) 

1B8AU  * 

M23A1 

99999: 

1330-H040 

Grenade,  Rifle;  smoke,  yellow,  impact 

MSR:  11756003  (DoDAC  :1330-H040) 

IBiSAV'  1 

:  ■  liill 

M26.-  •  MM 

1B8AW  i 

-  * 

■HP 

1B8AX 

M26A2 

Ug<?.Qd.: 

*  Item  identified  on  Table  A-l  for  smoke  munitions 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

£ _  TSM  Priority  of  I 

_ i  Non- Table  A-l  Equipments 


as  of  23  November,  1993 
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Model  Name 


_  EIACiHG 

1B8AY  M29  f 


Grenade,  Rifle;  practice,  delay 
MSR:  1 1756003  CDoDAC : 1330-G9 1 


1B8B2 


mm 


1B8B4 


19203 : 
D13-25-71 


1B8B7 


»  ^  lcc-a,  AMCTC 7764, ;; 

(DoDAAC :  1330-G887)  k  -  1 1 
19203  :  9231594  *  Grenade,  Hand;  fragmentation,  delay 
LCC-A,  AMCTC  6446 
1 _  (DoDAAC :  1330-G880) 


1B8B9 


I4  <*  re  r 


E^Oo  r.ustcr  Index 


Group  800  Table 
Mines  and  Grenades  (Continued) 


Notes  I  Model  Number  J  Part  Number 


1B8AX  |  M30 


1B8B3  *  I  M34 


1B8B5  *  M48 


19203 :  13-7-4  Grenade,  Hand;  smoke,  wp 
MSR:  11756003 
(DoDAC :  1330-G937) 


Grenade,  Hand;  smoke 
LCC-A,  MSR :  8746046 
oDAAC :  1330-G932) 


Leeend  : 


□ 


Item  identified  on  Tabic  A- 1  from  smoke  munitions 
Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 
TSM  Priority  of  1 
Non-  Table  A-l  Equipments 


as  of  23  November,  1993 
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ECDB  Master  Index 
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Group  800  Table 
Mines  and  Grenades  (Continued) 


Notes 

Model  Number 

Part  Number 

Model  Name 

EIAC:  HG 

Blue  Force  Equipments  Master  Index  List 

Hand  &  Rifle  Grenades  all  types 

1B8AY 

M29 

19203  :  8864102 

Grenade,  Rifle;  practice,  AT 

MSR:  1 1756003  (DoDAC  :1330-G980) 

1B8AX 

BBi 

19203  :  8861647 

Grenade,  Rifle;  practice,  delay 

MSR:  11756003  (DoDAC  :1330-G915) 

1B8B0 

M31 

19203 : 82-0-195 

Grenade,  Rifle;  beat 

MSR:  11756003  (DoDAC  :1330-G970) 

1B8B1 

M33 

19203 : 8810741 

Grenade,  Hand;  fragmentation,  delay 

MSR:  11756003  (DoDAC  :1330-G888) 

M33A1 

19203 : 8833936 

Grenade,  Hand;  fragmentation,  impact 

LCC-A,  AMCTC  7764 

(no  model/  part  number  matches) 

1B8B3  * 

M34 

19203 :  13-7-4 

Grenade,  Hand;  smoke,  wp 

MSR:  11756003 
(DoDAC :  1330-G937) 

1B8B4 

M47 

19203: 

D13-25-70 

Grenade,  Hand;  riot,  cs 

LCC-A,  MSR:  87446046 
(DoDAC  :1330-G922) 

1B8B5  * 

M48 

19203 : 

D13-25-71 

Grenade,  Hand;  smoke 

LCC-A,  MSR :  8746046 
(DoDAAC :  1330-G932) 

1B8H6 

M57 

. 

19203 : 9210138 

Grenade,  Hand;  fragmentation,  impact 

MSR:  10826016 

(no  model/  part  number  matches) 

1B8B7 

M58 

19203 : 13-21-16 

Grenade,  Hand;  riot,  pocket,  cs 

LCC-A,  MSR:  8746046 
(DoDAAC  :1330*G933) 

1B8B8 

M59 

19203 : 8833936 

.  •  ■  V  V'jXiX:?;-- X  ■ 

Grenade,  Hand;  fragmentation,  impact 

LCC-A,  AMCTC  7764, 

(DoDAAC :  1330-G887) 

1B8B9 

M61 

19203: 9231594 

-X  ■■■  ;•  : 

Grenade,  Hand;  fragmentation,  delay 

LCC-A,  AMCTC  6446 
(DoDAAC:  1330-G880) 

LtgendJ 


*  Item  identified  on  Table  A- 1  from  smoke  munitions 

+  Identified  as  a  priority  data  item  (Source  DDT  quarterly  report) 

#  TSM  Priority  of  1 

1  1  Non-Table  A- 1  Equipments 


as  of  23  November,  1993 
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Group  800  Table 
Mines  and  Grenades  (Continued) 


Notes 

Model  Number 

Part  Number 

m .■ ;  Model  Name  . 

'  •  ■  •  ••  •••-  .  .  '  ------- -rr-  . ,  - 

EIACtHG 

Blue  Force  Equipments  Master  Index  Last 

Band  &  Rifle  Grenades  all  types 

1B8BA 

M62 

19203  :  9231597 

Grenade,  Rifle;  practice,  delay 

MSR:  1 1756003  (DoDAC  :1 330-G9I4) 

1B8BB 

M67 

19203  :  9235492 

*  .  '  "  V 

••  •  :  .'f 

1B8BC 

■■  •  ■  •  --  ‘ ;•> 

•  •  :  ..  sMxjS 

•  .  ■  x  -  • 

M68 

$£:■:  •'  •  ;  £  ;■  \  f  •  •  -•  *  •:> 

19203  :  9235493 

Mg 
>  • 

~~1 

1B8BD  t 

M69 

i  .  .  . 

19203:  9235208 

|  §  • 

Grenade,  Rifle;  practice,  delay  ;;  T 

LCC-A,  AMCTC  8345 
(DoDAC :  1330-G918) 

1B8BE  * 

M76 

19203  : 

13-19-150 

Grenade,  Launcher,  smoke:  IR  screening 

LCC-A,  MSR  5856004 
(DoDAC  :1330-G826) 

Legend ; 

*  Item  identified  on  Table  A-l  from  smoke  munitions 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report; 

#  TSM  Priority  of  1 

I  Non-Table  A-l  Equipments 


as  of  23  November,  1993 


if.  >'1»- 
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Group  900  Table  509 
Obstacles,  Defilades,  Positions 


Model  Name 


tsMas 


i 


Obstacles,  Defilagws  &  Positions 
Group  800 


1B901  * 


1B903  * 


1B906  * 


1B907  * 


1B9A2  * 


1B9A3  * 


1B9A4  * 


1B9A5  * 


IB9C1  * 


IB9C2  * 


1B9C3  * 


EIAC:  Posit 


Obstacles  all 


Long  Cribs,  rectangle 


Long  Cribs,  triangle 


Tank  Ditch,  100*  x  44' 


Tank  Ditch,  200’ x  44’ 


Tank  Ditch,  300  x  44' 


Abatis,  14  tree 


Abatis,  8  tree 


Defilade  Positions  alt 


Defilade  Poistion,  mortar  carrier 


Defilade  Poistion,  fighting  vehicle 


Defilade  Poistion,  tank 


Defilade  Poistion,  armored  vehicle 


Defilade  Poistion,  mortar  carrier 


!  Positions  all 


Infantry  Fighting  Positions 


Machine  Gun  prepared  position 


Anti-armor  weapon  position 


Overhead  Cover  Infantry  Position 


Prestock  entities  all 


Prestock  :  Ammunition 


Prestock :  Fuel 


Legend  : 


rr 


Item  identified  on  Table  A-l 

Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 
TSM  Priority  of  I 
Non- Table  A- 1  Equipments 
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(in»U[>  AOU  Tabic 
I  S  Dismounted  Infantry  Forces 


Notes 

Model  Number 

Part  Number 

Model  Name 

Blue  Force  Equipments  Master  Index  List 

1BA00 

i 

US  Dismounted  Infantry  Forces  : 

Group  A00 

EIAC:  Dismount  I 

Dismounted  Forces  all  types 

1BA01 

TOE 

U.S  Scouts,  2  personnel,  SAW  &  Comm 

1BA02 

TOE 

US  ATGM,  2  personnel.  Dragon  &  M16 

1BA03 

38.36.2 

38.6.3 

TOE 

US  Infantry  Fire  Team,  6  personnel  weapons 

1BA04 

TOE 

US  Sniper,  Gunner  &  single  person 

1BA05 

TOE 

US  Dismounted  Engineer  Element,  10  person 

1BA06 

TOE: 

44-1752-400 

US  Stinger  Gunner,  single  person 

Legend  ; 

*  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

#  _  TSM  Priority  of  1 

___  Non- Table  A- 1  Equipments 


ns  of  23  November,  1993 
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Group  HOC  Table 
Environment :  Building,  Bridges 


Notes 

Model  Number 

Part  Number 

Model  Name 

!  ■  ■ 

EIAC:  Building; 

Blue  Force  Equipments  Master  Index  List 

Buildings/ Structures  of  all  types 

1BB00  * 

Covered  Machine  Gun  Bunker 

1BB01  * 

Indirect  Fire  Damaged  Building 

1BB02  * 

Burned-out  Building 

1BB03 

1BB04 

1BB05 

1BB06 

1BB07 

■ 

1BB08 

1BB09 

EIAC:  Bridge 

Bridges  of  all  types 

1BBC0  * 

Bridge,  60  ft,  AVLB  launched 

1BBC1  * 

Bridge,  Ribbon  10  section 

1BBC2  * 

Bridge,  ribbon,  14  section 

IBBC3 

1BBC4 

1BBC5 

IBBC6 

IBBC7 

1BBC8 

EIAC:  Fences 

Fences  of  all  types 

1BBF1  * 

Fence,  Concertina,  2  roll 

1BBF2  * 

Fence,  Concertina,  3  roll 

j 

Legend  : 

“  Item  identified  on  Table  A- 1 

+  Identified  as  a  priority  data  item  (Source  IDT  quarterly  report) 

f _  TSM  Priority  of  I 

_ )  Non-  Table  A- 1  Equipments 
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Group  COO  Table 
Ammunitions :  Cartridges 


FoVN 

Model  Number 

Part  Number 

Model  Name 

IB 

Blue  Force  Equipments  Master  Index  List 

EIAC:  Ammo 

Cartridges  of  all  types 

1BC01  * 

DM13 

19200 :  DM13 

CARTRIDGE,  Caliber  120  mm;  APFSDS-T 

1BC02  * 

DM23 

19200 :  DM23 

CARTRIDGE,  Caliber  120  mm;  APFSDS-T 

1BC03  * 

DM38 

19200 :  DM38 

CARTRIDGE,  Caliber,  120  mm;  LKL-  CKE 

1BC04  * 

DM128 

19200 :  DM128 

CARTRIDGE,  Caliber,  105  mm,  TPCSDS-T 

1BC05* 

Ml 

19200 :  Ml 
(50mm  Incend) 

CARTRIDGE,  Caliber  .50  mm,  incendiary 

1BC06* 

M1A1 

19200:  Ml  A1 

CARTRIDGE,  Caliber  .50  mm,  blank 

1BC07* 

M2 

CARTRIDGE,  Caliber  5.56  mm,  grenade 
launcher 

1BC08* 

M2 

19200 :  M2  (AP) 

CARTRIDGE,  Caliber  .50  mm,  armor  piercing 
incendiary 

1BCX)9  * 

M2 

CARTRIDGE,  Caliber  .50  mm,  ball 

1BC10  * 

M2 

CARTRIDGE,  Caliber  .50  mm,  dummy 

1BC11  * 

M2 

19200 :  M2 
(Plain) 

CARTRIDGE,  Caliber  .50  mm,  plain  tip 

1BC12  * 

M2A1 

19200  ;M2A1 

CARTRIDGE,  Caliber  4.2  inch;  Gas 

1BC13  * 

M8 

CARTRIDGE,  Caliber  .50  mm,  armor  piercing 
incendiary 

1BC14* 

M10 

19200 :  M10 

CARTRIDGE,  Caliber  .50  mm,  tracer 

1BC15  * 

M17 

19200:  M17 

CARTRIDGE,  Caliber  .50  mm,  tracer 

1BC16  * 

M20 

19200 :  M20 

CARTRIDGE,  Caliber  .50  mm,  incendiary 

1BC17  * 

M21 

19200 :  M21 

CARTRIDGE,  Caliber  .50  mm,  tracer 

1BC18  * 

M23 

19200 :  M23 

CARTRIDGE,  Caliber  .50  mm,  incendiary 

1BC19* 

M33 

19200 :  M33 

CARTRIDGE,  Caliber  .50  mm.  Ball 

1BC20  * 

M51A2 

19200:  MSI  A2 

CARTRIDGE,  Caliber  20  mm,  dummy 

1BC21  * 

M55A2 

19200 :  M55A2 

CARTRIDGE,  Caliber  20  mm.  Target 

Practice  -  Tracer 

1BC22  * 

M56A3 

19200 :  M56A3 

CARTRIDGE,  Caliber  20  mm.  High 

Expolsive  -  Incendiary 

1BC23  * 

M56A4 

19200 :  M56A4 

CARTRIDGE,  Caliber  20  mm.  High 

Expolsive  -  Incendiary 

Lcggnd; 

*  Item  identified  on  Table  A- 1 
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ECDB  Master  Index 
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Group  COO  Table 
Ammunitions :  Cartridges 


FoVN 

Model  Number 

Part  Number 

Model  Name 

IB 

EIAC:  Ammo 

Blue  Force  Equipments  Master  Index  List 

Cartridges  of  all  types 

1BC24  * 

M59 

19200  M59 

CARTRIDGE,  Caliber  7.62  mm,  ball 

1BC25  * 

M61 

19200  M61 

CARTRIDGE,  Caliber  7.62  mm,  ball 

1BC26  * 

M62 

19200  M62 

CARTRIDGE,  Caliber  7.62  mm,  tracer 

1BC27* 

M63 

19200  M63 

CARTRIDGE,  Caliber  7.62  mm,  tracer 

1BC28* 

M80 

19200  M80 

CARTRIDGE,  Caliber  7.62  mm,  ball 

1BC29  * 

M82 

19200  M82 

CARTRIDGE,  Caliber  7.62  mm,  blank 

1BC30* 

Ml  93 

19200  M193 

CARTRIDGE,  Caliber  5.56  mm,  ball 

1BC31  * 

M196 

19200  Ml  96 

CARTRIDGE,  Caliber  5.56  mm,  tracer 

1BC32  * 

M199 

19200  Ml  99 

CARTRIDGE,  Caliber  5.56  mm,  dummy 

1BC33  * 

M200 

19200  M200 

CARTRIDGE,  Caliber  5.56  mm,  blank 

1BC34  * 

M220 

19200  M220 

CARTRIDGE,  Caliber  20  mm,  TP-T 

1BC35* 

M246 

19200  M246 

CARTRIDGE,  Caliber  20  mm;  HETT-SD 

1BC36* 

M246A1 

19200  M246A1 

CARTRIDGE,  Caliber  20  mm;  HEIT-SD 

1BC37  * 

M328 

19200  M328 

CARTRIDGE,  Caliber  4.2  inch.  Smoke 

1BC38  * 

M328A1 

19200  M328A1 

CARTRIDGE,  Caliber  4.2  inch.  Smoke 

1BC39* 

M329 

19200  M329 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC40* 

M329A1 

19200  M329A1 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC41  * 

M329B1 

19200  M329B1 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC42  * 

M335 

19200  M335 

CARTRIDGE,  Caliber  4.2  inch.  Illumination 

1BC43* 

M335A1 

19200  M335A1 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC44* 

M335C1 

19200  M335C1 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC45  * 

M381 

19200  M381 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

1BC46* 

M382 

19200  M382 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

1BC47* 

M383 

19200  M383 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

LcerndJ 
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Group  COO  Table 
Ammunitions :  Cartridges 


FoVN 

Model  Number 

Part  Number 

Model  Name 

IB 

Blue  Force  Equipments  Master  Index  List 

E1AC:  Ammo 

Cartridges  of  all  types 

1BC48* 

M385A1 

19200  M385A1 

CARTRIDGE,  Caliber  40  mm.  Training 

Practice 

1BC49* 

M385E4 

19200  M385E4 

CARTRIDGE,  Caliber  40  mm.  Training 

Practice 

1BC50* 

M386 

19200 :  M386 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

1BC51  * 

M387 

19200 :  M397 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 
-  Air  Burst 

1BC52  * 

M392 

19200 :  M392 

CARTRIDGE,  Caliber,  105  mm;  APDS-T 

1BC53  * 

M393 

19200 :  M393 

CARTRIDGE,  Caliber,  105  mm;  HEP-T 

1BC54* 

M393A1 

19200 :  M393A1 

CARTRIDGE,  Caliber,  105  mm,  TP-T 

1BC55* 

M3A9A2 

19200  :  M329A2 

CARTRIDGE,  Caliber  4.2  inch.  High 

Explosive 

1BC56  * 

M406 

19200 :  M406 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

1BC57  * 

M407A1 

19200 :  M407A1 

CARTRIDGE,  Caliber  40  mm.  Training 

Practice 

1BC58  * 

M416 

19200 :  M416 

CARTRIDGE,  Caliber,  105  mm,  smoke  WP-T 

1BC59  * 

M430 

19200 :  M430 

CARTRIDGE,  Caliber  40  mm.  High  Explosive- 
Dual  Purpose 

1BC60  * 

M433 

19200 :  M433 

mmSSmSm 

1BC61  * 

M441 

19200 :  M441 

CARTRIDGE,  Caliber  40  mm.  High  Explosive 

1BC62  * 

M456 

19200 :  M456 

CARTRIDGE,  Caliber,  105  mm,  HEAT-T 

1BC63  * 

M457 

19200 :  M457 

CARTRIDGE,  Caliber,  105  mm,  dummy 

1BC64  * 

M467 

19200 :  M467 

CARTRIDGE,  Caliber,  105  mm,  TP-T 

1BC65  * 

M490 

19200 :  M490 

CARTRIDGE,  Caliber,  105  mm,  TP-T 

1BC66  * 

M494 

19200 :  M494 

CARTRIDGE,  Caliber,  105  mm,  APERS-T 

1BC67* 

M630 

19200 :  M630 

CARTRIDGE,  Calibaer  4.2  inch.  Tactical 

1BC68  * 

M728 

19200 :  M728 

CARTRIDGE,  Caliber,  105  mm;  APDS-T 

1BC69  * 

M735 

19200 :  M735 

CARTRIDGE,  Caliber,  105  mm;  APFSDS-T 

1BC70  * 

M774 

19200 :  M774 

CARTRIDGE,  Caliber,  105  mm,  APFSDS-T 

1BC71  * 

M829 

19200 :  M829 

CARTRIDGE,  Caliber,  120  mm,  APFSDS-T 

Legend ; 

*  Item  identified  on  Table  A- 1 
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Group  COO  Table 
Ammunitions :  Cartridges 


FoVN 

Model  Number 

Part  Number 

Model  Name 

IB 

EIAC:  Ammo 

Blue  Force  Equipments  Master  Index  List 

Cartridges  of  all  types 

.  1BC72  * 

M829A1 

19200 :  M829A1 

CARTRIDGE,  Caliber,  120  mm,  APFSDS-T 

1BC73  * 

M830 

19200 :  M830 

CARTRIDGE,  Caliber,  120  mm,  HEAT-MP-T 

1BC74  * 

M831 

19200:  M831 

CARTRIDGE,  Caliber,  120  mm,  Target 

Practice  -  Tracer 

1BC75  * 

M865 

19200 :  M865 

CARTRIDGE,  Caliber,  120  mm,  TPCSDS-T 

1BC76  * 

M918 

19200 :  M918 

CARTRIDGE,  Caliber,  40  mm.  Target 

Practice 

1BC77* 

PATEC 

19200 :  PATEC 

CARTRIDGE,  Caliber,  40  mm 

1BC78  * 

XM195 

19200 :  XM195 

CARTRIDGE,  Caliber,  5.56  mm  grenade 

1BC79  * 

XM576E1 

19200 : 

XM576E1 

CARTRIDGE,  Caliber,  40  mm.  Multiple 
Projectile 

1BC80  * 

XM576E2 

19200 : 

XM576E2 

CARTRIDGE,  Caliber,  40  mm.  Multiple 
Projectile 

1BC81  * 

XM583 

19200 :  XM583 

CARTRIDGE,  Caliber,  40  mm.  White  Star  - 
Parachute 

1BC82* 

XM585 

19200 :  XM585 

CARTRIDGE,  Caliber,  40  mm.  White  Star  - 
Cluster 

1BC83* 

XM651E1 

19200 : 

XM651E1 

CARTRIDGE,  Caliber,  40  mm.  Tactical 

XM661 

19200 :  XM661 

CARTRIDGE,  Caliber,  40  mm.  Green  Star  - 
Parachute 

1 BC85  * 

XM662 

19200 :  XM662 

CARTRIDGE,  Caliber,  40  mm.  Red  Star  - 
Parachute 

1BC86* 

XM663 

19200 :  XM663 

CARTRIDGE,  Caliber,  40  mm.  Green  Star  - 
Cluster 

1BC87  * 

! 

XM664 

19200 :  XM664 

CARTRIDGE,  Caliber,  40  mm.  Red  Star  - 
Ouster 

1BC88* 

XM674 

19200 :  XM674 

CARTRIDGE,  Caliber,  40  mm.  Riot  Control 

1BC89  * 

XM676 

19200 :  XM676 

CARTRIDGE,  Caliber,  40  mm.  Smoke  Canopy 

Legend; 
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Group  COO  Table 
Ammunitions :  Cartridges 


FoVN 

Model  Number 

Part  Number 

Model  Name 

IB 

Blue  Force  Equipments  Master  Index  List 

EIAC:  Ammo 

Cartridges  of  all  types 

1EC90* 

XM679 

19200 :  XM679 

CARTRIDGE,  Caliber,  40  mm.  Smoke  Canopy 

1BC91  * 

XM680 

19200 :  XM680 

CARTRIDGE,  Caliber,  40  mm.  White  Smoke 
Canopy 

1BC92  * 

XM681 

19200:  XM681 

CARTRIDGE,  Caliber,  40  mm,  Violet  Smoke 
Canopy 

1BC93  * 

XM682 

19200 :  XM682 

CARTRIDGE,  Caliber,  40  mm.  Red  Smoke 
Canopy 

1BC94  * 

XM695 

19200 :  XM695 

CARTRIDGE,  Caliber,  40  mm.  Orange  Star  - 
Parachute 

Legend ; 
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INITIAL  EFFORT 


INTERACTIVE  MENU  SYSTEM 


DEFINE  DATA  ELEMENTS,  CODES,  AND  CURRENCY  OF  DATA 


CFDB  V3.0 

MAJOR  FUNCTIONAL  AREAS 


!.  UNIT  DATA  DISPLAY  4.  UNIT  DATA  DISPLAY 


JOINT  MODELING  &  SIMULATION  DA  TA  BASE  SUPPORT  -  CFDB/MSDS 


USCENTCOM’S  MODELING  DATA  ARCHITECTURE 
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A  framework  for  providing  data  quality 


633 


sources/“owners”  Improve 

of  data  &  processes 


Quality  depends  on  metadata  at  three  levels 
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Note:  Inheritance/defaulting  of  metadata  can  reduce  redundancy 

-  i.e.,  need  not  have  every  metadata  item  present  everywhere 
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iTAKEl 
PRIDE  IN 


United  States  Department  of  the  Interior  America! 


GEOLOC.K  ALSL  RVtV 

RcM.HI.  V  \  Jl.’ll'l-J 


In  Reply  Refer  To: 
Mail  Stop  519 


MEMORANDUM 


January  27,  1994 


To:  FGDC  Standards  Working  Group 

From:  Chairman,  FGDC  Standards  Working  Group 

Subject:  Draft  Content  Standards  for  Spatial  Metadata 

Attached  is  the  version  of  the  Content  Standards  for  Spatial  Metada  that  resulted 
from  the  FGDC  Standards  Working  Group  Meeting  of  January  25, 1994.  The 
FGDC  Coordination  Group  has  received  a  copy  and  has  been  asked  to  review  it  by 
their  next  meeting  at  the  end  of  February.  The  plan  is  for  the  FGDC  Steering 
Committee  to  approve  the  Standard  at  their  March  2, 1994,  meeting.  Please  give 
thifl  version  a  final  review.  Submit  any  comments  you  have  directly  to  Mike 
Domaratz  (Telephone:  703-648-4533;  FAX:  703-648-5755)  by  February  11, 1994. 
Thanks  in  advance  for  all  your  help. 


iL  idJ 


Stephen  C.  Guptill 
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Federal  Geographic  Data  Committee 

January  25,  1994 


Federal  Geographic  Dm  Committee 

Department  of  Agriculture  -  Department  of  Commerce  -  Department  of  Defense  -  Department  of  Energ> 
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Department  of  Transportation  -  Environmental  Protection  Agency 
Federal  Emergency  Management  Agency  Library  of  Congress 
National  Aeronautics  and  Space  Administration  -  National  Archives  and  Records  Administration 

Tennessee  Valley  Authority 
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Federal  Geographic  Data  Committee 


Established  by  Office  of  Management  and  Budget  Circular  A- 16.  the  Federal  Geographic  Data  Committee 
(FGDC)  promotes  the  coordinated  development,  use.  sharing,  and  dissemination  of  geographic  data. 

The  FGDC  is  composed  of  representatives  from  the  Departments  of  Agriculture.  Commerce.  Defense.  Eneray 
Housing  and  Urban  Development,  the  Interior.  State,  and  Transportation;  the  Environmental  Protection  Agency 
the  Federal  Emergency  Management  Agency;  the  Library  of  Congress;  the  National  Aeronautics  and  Space 
Administration;  the  National  Archives  and  Records  Administration;  and  the  Tennessee  Valley  Authoritv 
Additional  Federal  agencies  participate  on  FGDC  subcommittees  and  working  groups.  The  Department  of  the 
Interior  chairs  the  committee. 

FGDC  subcommittees  work  on  issues  related  to  data  categories  coordinated  under  the  circular.  Subcommittees 
establish  and  implement  standards  for  data  content,  quality,  and  transfer;  encourage  the  exchange  of  information 
and  the  transfer  of  data;  and  organize  the  collection  of  geographic  data  to  reduce  duplication  of  effort  Working 
groups  are  established  for  issues  that  transcend  data  categories. 

For  more  information  about  the  committee,  or  to  be  added  to  the  newsletter  mailing  list,  please  contact: 

Federal  Geographic  Data  Committee  Secretariat 
c/o  U.S.  Geological  Survey 
590  National  Center 
Reston,  Virginia  22092 

Facsimile;  (703)  648-5755 
Internet;  gdc@usgs.gov 


Federal  Geographic  Data  Committee 

Department  of  Agriculture  -  Department  of  Commerce  •  Department  of  Defense  •  Department  of  Energy 
Department  of  Housing  and  Urban  Development  -  Department  of  the  Interior  -  Department  of  State 
Department  of  Transportation  Environmental  Protection  Agency 
Federal  Emergency  Management  Agency  -  Library  of  Congress 
National  Aeronautics  and  Space  Administration  National  Archives  and  Records  Administration 

Tennessee  Valley  Authority 
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0 

0.1 


Metadata 

Metadata  -  data  about  the  content,  quality,  condition,  and  other  characteristics  about  data 
Type:  compound 

Metadata  Element  Context  Syntax: 


Metadata  = 

Identification  lnformation  - 
(Spatial_Reference)  - 
Statusjnformation  ♦ 
0{Source_Information}n  * 
Processing_History_[nformation  * 
Entity/Attributelnformation 
Distributionjnformation  * 
Metadata_Reference_information  - 
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Identification  Information 

I  Identification  Information  -•  identifiers  and  basic  information  about  the  data  set 

Type:  compound 

I  I  Data  Set  Identity  --  the  name  or  title  by  which  the  data  set  is  known. 

Type:  text 

Domain:  free  text 

1.2  Identification  Code  —  unique  item  or  stock  code  by  which  the  item  can  be  ordered 

Type:  text 

Domain:  free  text  "Not  applicable"  "Unknown" 

1 .3  Data  Set  Description  ••  a  description  of  the  spatial  data  set,  including  its  intended  use 
and  limitations. 

Type:  text 

Domain:  free  text 

1 .4  Theme  --  subjects  covered  by  the  data  set. 

Type:  compound 

1  4  i  Theme  Keyword  --  common-use  word  or  phrase  used  to  describe  the  thematic 

content  of  a  data  set. 

Type:  text 

Domain:  free  text  (see  Appendix  B  for  the  default  domain) 

1.4.2  Theme  Keyword  Thesaurus  -  reference  to  a  formally  registered  thesausus  or 

similar  authoritative  source  of  theme  keywords. 

Type:  text 

Domain:  free  text  "None"  (see  Appendix  B  for  the  draft  thesaurus  title) 

15  Data  Currentness  and  Quality  Summary  -•  a  general  assessment  of  currentness  and 

quality  of  the  non-positional  aspects  of  the  data  set.  See  section  3.  "Spatial  Data 
Quality,"  of  the  Spatial  Data  Transfer  Standard  (Federal  Information  Processing 
Standard  173),  for  additional  background  on  accuracy  assessments. 

Type:  compound 

1.5.1  Beginning  Date  of  Information  Content  -  earliest  or  only  date  for  which  the 

are  valid.  In  cases  when  a  range  of  dates  are  provided,  this  is  the  earlir it 
date  for  which  the  information  are  valid. 

Type:  date 

15  2  Ending  Date  of  Information  Content  -  latest  date  for  which  the  information  are 

valid.  Used  in  cases  when  a  range  of  dates  are  provided. 

Type:  date 

1.5  3  Thematic  Quality  —  an  assessment  of  the  certainty  of  the  identification  of 

entities  and  assignment  of  attribute  values  in  the  data  set. 

Type:  compound 

15  3  1  Quantitative  Thematic  Accuracy  Assessment  —  numeric  value  assigned  to 

the  certainty  of  the  identification  of  the  entities  and  assignments  of  values 
in  the  data  set  and  the  description  of  the  tests  used. 

Type:  compound 
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1 .5.3. 1.1  Thematic  Accuracy  -  an  estimate  of  the  certainty  of  the 

identification  of  the  entities  and  assignments  of  values  in  the  data 
set.  expressed  as  a  percentage 

Type  integer 

Domain  0  <=  Thematic  Accuracy  <=  1 00  "Unknown" 

"Not  applicable" 

I  5.3. 1.2  Thematic  Accuracy  Explanation  --  a  definition  of  the  thematic 

accuracy  measure,  and  a  description  of  how  the  estimate  was 
derived. 

Type:  text 

Domain:  free  text 

1. 5.3.2  Qualitative  Thematic  Accuracy  Assessment  -  an  explanation  of  the 

certainty  of  the  identification  of  the  entities  and  assignments  of  values  in 
the  data  set  and  the  tests  used. 

Type:  text 

Domain:  free  text 

1.5.4  Logical  Consistency  -  an  explanation  of  the  fidelity  of  the  relationships  in  the 

data  set  and  the  tests  used. 

Type:  text 

Domain:  free  text  "Not  applicable"  "Unknown" 

1.5.5  Completeness  --  information  about  omissions,  selection  criteria,  generalization. 

definitions  used,  and  other  rules  used  to  derive  the  data  set. 

Type:  text 

Domain:  free  text  "Not  applicable"  "Unknown” 

1.5.6  Horizontal  Positional  Quality  -  an  estimate  of  locational  certainty  of  the 

horizontal  positions  of  the  spatial  objects. 

Type:  compound 

1.5.6. 1  Quantitative  Horizontal  Positional  Accuracy  Assessment  -  numeric  value 

of  the  locational  certainty  of  a  horizontal  coordinate  measurement  and  a 
description  of  the  tests  used. 

Type:  compound 

1.5.6. 1.1  Horizontal  Positional  Accuracy  -  an  estimate  of  the  locational 

certainty  of  the  horizontal  coordinate  measurement  in  the  data  set 
expressed  in  meters. 

Type:  real 

1.5.6. 1.2  Horizontal  Positional  Accuracy  Explanation  ~  a  definition  of  the 

horizontal  positional  accuracy  measure  and  how  the  estimate  was 
derived. 

Type:  text 

Domain,  free  text 

1. 5.6.2  Qualitative  Horizontal  Positional  Accuracy  Assessment  ~  an  explanation 

of  the  locational  certainty  of  a  horizontal  coordinate  measurement  and  a 
description  of  the  tests  used. 

Type:  text 

Domain:  free  text  "Not  applicable" 
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1.5.7 

1 .5.7. 1 

1 .5.7.1. 1 

1.5.7. 1.2 

1. 5.7.2 

1.5.8 

1.6 

1.6.1 

1.6.2 

1.6.3 

1.6.4 

1.7 

1.7.1 


Vertical  Positional  Quality  -  an  estimate  of  locational  certainty  of  the  vertical 
positions  of  the  spatial  objects. 

Type:  compound 

Quantitative  Vertical  Positional  Accuracy  Assessment  --  numeric  value  of 
the  locational  certainty  of  a  vertical  coordinate  measurement  and  a 
description  of  the  tests  used. 

Type.  compound 

Vertical  Positional  Accuracy  --  an  estimate  of  the  locational 
certainty  of  the  vertical  coordinate  measurement  in  the  data  set 
expressed  in  meters. 

Type:  real 

Vertical  Positional  Accuracy  Explanation  -  a  definition  of  the 
vertical  positional  accuracy  measure  and  how  the  estimate  was 
derived. 

Type:  text 

Domain:  free  text 

Qualitative  Vertical  Positional  Accuracy  Assessment  --  an  explanation  of 
the  locational  certainty  of  a  vertical  coordinate  measurement  and  a 
description  of  the  tests  used. 

Type:  text 

Domain:  free  text 

Cloud  Cover  -•  area  of  a  data  set  obstructed  by  clouds,  expressed  as  a 
percentage  of  the  spatial  extent. 

Type:  integer 

Domain:  0  <=  Cloud  Cover  <=  100  "Unknown" 

Bounding  Coordinates  -  the  limits  of  coverage  of  a  data  set  expressed  by  latitude  and 
longitude  values  in  the  order  western-most,  eastern-most,  northern-most,  and  southern¬ 
most. 

Type:  compound 

West  Bounding  Coordinate  -  western-most  coordinate  of  the  limit  of  coverage. 

Type:  compound 

East  Bounding  Coordinate  -  eastern-most  coordinate  of  the  limit  of  coverage. 

Type:  compound 

North  Bounding  Coordinate  -  nonhem-most  coordinate  of  the  limit  of  coverage. 

Type:  compound 

South  Bounding  Coordinate  —  southern-most  coordinate  of  the  limit  of  coverage. 
Type:  compound 

Data  Set  O-Polygon  -  the  interior  areals)  covered  by  a  data  set. 

Type:  compound 

Data  Set  G-Polygon  Outer  G-Rmg  -  the  closed  nonintersecting  boundary  of  an 

interior  area. 

Type:  compound 
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1.7.2 


1.8 


1.8  I 


1.8.2 


1.9 


1.9.1 


1.9.2 


1.9.3 


Data  Set  G-Polygon  Exclusion  G-Ring  --  the  closed  nomntersecting  boundary  of  a 
void  area  (or  "hole")  in  an  interior  area. 

Type.  compound 

Geographic  Keyword  -  the  names  and  types  of  significant  areas  and  or  places  that  fall 
w  ithin  the  extent  of  the  data  set 
Type;  compound 

Geographic  Keyword  Name  -  the  geographic  name  of  significant  areas  and  or  places 
that  fail  within  the  extent  of  the  data  set. 

Type:  text 

Domain:  free  text 

Geographic  Keyword  Type  --  the  geographic  type  of  significant  areas  and  or  places 
that  fall  within  the  extent  of  the  data  set. 

Type:  text 

Domain:  "airport"  "arch"  "area"  "arroyo"  "bar"  "basin"  "bay"  "beach"  "bench" 

"bend"  "bridge"  "building"  "canal"  "cape"  "cave"  "cemetery" 

"census  unit"  "channel"  "church"  "city”  "cliff'  "county"  "crater" 
"crossing"  "dam"  "falls"  "flat"  "forest”  "gap”  "geyser"  "glacier" 

"gut”  "harbor"  "hospital"  "island"  "isthmus"  "lake"  "lava"  "levee" 
"locale"  "mine"  "minor  civil  division"  "nation”  "oilfield"  "park" 
"pillar"  "plain"  "range"  "rapids"  "reserve"  "reservoir"  "ridge" 

"school"  "sea"  "slope"  "spring"  "state/territory"  "stream"  "summit" 
"swamp"  "trail"  "tower"  "tunnel"  "valley"  "well"  "woods"  free  text 

Browse  Graphic  -  a  graphic  that  provides  an  illustration  of  the  data  set.  The  graphic 
should  include  a  legend  for  interpreting  the  graphic. 

Type:  compound 

Browse  Graphic  File  Name  name  of  a  related  graphic  file  that  provides  an 
illustration  of  the  data  set,  including  a  legend  for  interpreting  the  graphic. 

Type:  text 

Domain:  free  text 

Browse  Graphic  File  Description  -  a  text  description  of  the  illustration. 

Type:  text 

Domain:  free  text 

Browse  Graphic  File  Type  -  graphic  file  type  of  a  related  graphic  file. 


Type- 

Domain: 

text 

Domain 

Valyg 

Definition 

"CGM" 

Computer  Graphics  Metafile 

"GIF" 

Graphic  Interchange  Format 

"JPEG" 

Joint  Photographic  Experts  Group  format 

"PS" 

Postscript  format 

"TIFF" 

Tagged  Image  File  Format 
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1.10  Data  Set  Citation  --  the  recommended  reference  to  be  used  for  the  data  set 

Type.  text 
Domain:  free  text 

Form:  For  recommended  forms,  see  Patrias.  Karen,  1991.  National  Library 

of  Medicine  recommended  formats  for  bibliographic  citations 
(April):  Bethesda.  Maryland.  U  S.  Department  of  Health  and 
Human  Services.  Public  Health  Service.  National  Institutes  of 
Health.  National  Library  of  Medicine;  and  Clark.  Suzanne. 
Larsgaard.  Mary,  and  Teague.  Cynthia.  1992.  Cartographic  citations 
a  style  guide:  Chicago.  American  Library  Association.  Map  and 
Geography  Roundtable. 

1.11  Native  Data  Set  Environment  --  a  description  of  the  data  set  in  the  producer's 
processing  environment.  For  digital  data,  include  items  such  as  the  name  of  the 
software  (including  version),  the  computer  operating  system,  file  name  (including 
host-,  path-,  and  filenames),  and  the  data  set  size.  For  non-digital  spatial  data  (such 
as  maps),  include  a  discussion  of  the  medium  and  the  scale. 

Type:  text 

Domain:  free  text 

1.12  Use  Restrictions  --  terms,  including  copyright,  governing  the  use  of  the  data  set  after 
access  has  been  provided. 

Type:  text 

Domain:  free  text 

1.13  Access  Restrictions  --  restrictions  imposed  on  access  or  distribution  of  the  data  set. 

Type:  text 

Domain:  free  text 

1.14  Security  Information  -  handling  restrictions  imposed  on  the  data  set  because  of 
national  security,  privacy,  or  other  concerns. 

Type:  compound 

1.14.1  Security  Classification  -  name  of  the  handling  restrictions  on  the  data  set 

Type:  text 

Domain:  Top  secret"  "Secret"  "Confidential”  "Restricted" 

"Unclassified"  free  text 

1.14.2  Security  Handling  Description  -  additional  information  about  the  restrictions  on 

handling  the  data  set. 

Type:  text 

Domain:  free  text 

1.15  String  -  A  connected  nonbranching  ordered  sequence  of  points. 

Type:  compound 

1.16  Latitude  -  angular  distance  measured  on  a  meridian  north  or  south  from  the  equator 
Expressed  in  degrees. 

Type:  real 

Domain:  -90.0  <*  Latitude  <*  90.0 

l.|7  Longitude  -  the  angle  between  the  plane  of  a  given  meridian  and  the  plane  of  the 

meridian  of  Greenwich.  Expressed  in  degrees. 

Type:  real 

Domain:  -180.0  <-  Longitude  <  180.0 
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Identification  Element  Context  Syntax: 

Identificationlnformation  = 

Data_Set_!dentity  * 

Identification  Code  - 
Data_Set_Description  - 
Theme  ~ 

Data_Currentness_and_Quality_Summary  * 
Bounding_Coordinates  - 
( 1  { Data_Set_G-Polygon }  n) 

(I  {Geographic_Keyword}n)  * 
(l{Browse_Graphic}n) 

(Data_Set_Citation) 
(Native_Data_Set_Environment)  + 
(Use_Resmctions)^  + 

(Access_Restrictions)+ 

(Security_lnformation) 


Theme  = 


1{  !  {Theme_Keywords}n  ♦ 
Theme_Keyword_Thesausus }  n 


Data_Currentness_and_Quality_Summary  * 

Beginning_Date_of_Information_Content  + 
(Ending_Date_of_Information_Content)  + 
Thematic_Quality  -t- 
Logical_Consistency  + 

Completeness  + 

Horizontal_Positional_Quality  + 

(  V  ertical_Positional_Quality )  + 
(Cloud_Cover) 


ThematicQuality  = 

[Quamitative  Thematic  Accuracy  Assessment  | 
Qualitative_Thematic_Accuracy_Assessment] 

Quantitative_Thematic_Accuracy_  Assessment  * 

Thematic_  Accuracy  + 

Thematic  Accuracy_Explanation 

Horizontal_Positional_Quality  * 

(Quantitative_Horizonul_Positional_Accuracy_Assessment 
Qualitative_Hori2omal_Positional_Accuracy_Assessment  | 

Quantitative_Horizontal_Positional_Accuracy_Assessment  - 

Horizontal_Positiona]_Accuracy  + 
HonzontaJ_Positional_Accuracy_Explanation 

Vertical_Positional_Quality  - 

[Quantitaiive_Vertical_PositionaI_Accuracy_Assessment 
Qualitative_Vertical_PositionaJ_Accuracy_Asscssment  | 

Quantitative_Vertical_Positional_Accuracy_Assessment  - 

Venical_Positional_  Accuracy  + 
Vcrtical_Positional_Accuracy_Expl«nation 
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Bounding_Coordinates  = 

WestBoundmgCoordinate  - 
East_Bounding_Coordinate  - 
North  Bounding  Coordinate  - 
SouthBoundingCoordinate 

WestBoundmgCoordinate  = 

Longitude 

EastBoundingCoordinate  = 

Longitude 


North_Bounding_Coordinate  = 

Latitude 


South_Bounding_Coordinate  = 

Latitude 


Data_Set_G-Polygon  = 

Data_Set_G-Polygon_Outer_G-Ring  + 

0  { Data_Set_G-Polygon_ Exclusion  G-Ring}  n 


Data_Set_G-Polygon_Outer_G-Ring  = 

String 


Data_Set_G-Polygon_Exclusion_G-Ring  = 

String 


Geographic  Keyword  * 


Browse  Graphic  * 


Securitylnformation  - 


String  “ 


Geograph  ic_Keyword_Name  + 
GeographicKeywordType 


Browse_Graphic_File_Name  + 

Browse_Graphic_File_Description 

BrowseGraphicFileTypc 


Security_Classification  + 
SecurityHandlingDescription 


4  {Latitude  + 
Longitude  }n 
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2.1 


2.2 


2.3 


2.3.1 


2.3. 1.1 


2.3.U.I 


2.3. 1.2 


2.3.12.1 


2.3. 1.2.1. I 


Revised  Draft 


Spatial  Reference 

Spatial  Reference  --  description  of  the  locational  data  or  references  in  the  data  set 
Type.  compound 

Native  Spatial  Data  Structure  --  the  mechanism  used  to  represent  spatial  information 
in  the  data  set. 

Type:  text 

Domain:  "Point"  "Vector”  "Raster"  '  Indirect" 

Indirect  Spatial  Reference  --  name  of  types  of  geographic  features,  addressing 
schemes,  or  other  means  through  which  locations  are  referenced  in  the  data  set 
Type:  text 

Domain:  free  text 

Direct  Spatial  Reference  --  description  of  the  means  and  coordinate  systems,  and 
spatial  objects  used  to  encode  locational  information  in  the  data  set. 

Type:  compound 

Horizontal  Coordinate  System  Definition  --  the  reference  frame  or  system  from 
which  linear  or  angular  quantities  are  measured  and  assigned  to  the  position 
that  a  point  occupies. 

Type:  compound 

Geographic  —  the  quantities  of  latitude  and  longitude  which  define  the 
position  of  a  point  on  the  Earth’s  surface  with  respect  to  a  reference 
spheroid. 

Type:  compound 

Geographic  Coordinate  Units  -  units  of  measure  used  for  the 
latitude  and  longitude  values. 

Type:  text 

Domain:  "Decimal  degrees"  "Degrees  and  decimal  minutes" 
"Degrees,  minutes,  and  decimal  seconds” 

"Radians"  "Grads" 

Planar  ~  the  quantities  of  distances,  or  distances  and  angles,  which  define 
the  position  of  a  point  on  a  reference  plane  to  which  the  surface  of  the 
Earth  has  been  projected. 

Type:  compound 

Map  Projection  -  the  systematic  representation  of  all  or  pan  of  the 
surface  of  the  Earth  on  a  plane  or  developable  surface.  (A 
developable  surface  is  one  that  can  be  flattened  to  form  a  plane 
without  compressing  or  stretching  any  part  of  it.  Examples  include 
cones  and  cylinders.) 

Type:  compound 

Map  Projection  Name  —  name  of  the  map  projection. 

Type:  text 

Domain:  "Albers  Conical  Equal  Area"  "Azimuthal 
Equidistant"  "Equidistant  Conic” 
"Equirectangular"  "General  Vertical  Near¬ 
sided  Projection"  "Gnomomic”  "Lambert 
Azimuthal  Equal  Area” 

"Lambert  Conformal  Conic”  "Mercator 
"Modified  Stereographic  for  Alaska" 
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2.3.1. 2.1.2 


2. 3. 1.2. 1.2.1 


2.3. 1.2. 1.2 .2 


2.3. 1.2. 1.2.3 


2.3. 1.2. 1.2.4 


2.3. 1.2. 1.2.5 


2.3.1.2.1.2.6 


"Miller  Cylindrical"  "Oblique  Mercator" 
"Orthographic"  "Polar  Stereographic'' 
"Polvconic"  "Robinson"  "Sinusoidal"  "Space 
Oblique  Mercator"  "Stereographic" 

"Transverse  Mercator”  "van  der  Grinten'' 

Albers  Conical  Equal  Area.  Azimuthal  Equidistant. 

Equidistant  Conic,  Equirectangular,  General  Vertical  Near¬ 
sided  Projection.  Gnomomic.  Lambert  Azimuthal  Equal  Area. 
Lambert  Conformal  Conic,  Mercator,  Modified  Stereographic 
for  Alaska.  Miller  Cylindrical,  Oblique  Mercator. 

Orthographic,  Polar  Stereographic.  Polyconic.  Robinson. 
Sinusoidal,  Space  Oblique  Mercator,  Stereographic.  Transverse 
Mercator,  van  der  Grinten  -  specific  map  projections,  each 
having  a  unique  mathematical  relationship  between  the  Earth 
and  the  plane  or  developable  surface. 

Type:  compound 

Standard  Parallel  -  line  of  constant  latitude  at  which  the 
surface  of  the  Earth  and  the  plane  or  developable  surface 
intersect. 

Type:  compound 

Longitude  of  Central  Meridian  ~  the  line  of  longitude  at 
the  center  of  a  map  projection  generally  used  as  the 
basis  for  constructing  the  projection. 

Type:  compound 

Latitude  of  Projection  Origin  ~  latitude  chosen  as  the 
origin  of  rectangular  coordinates  for  a  map  projection 
Type:  compound 

False  Easting  --  the  value  added  to  all  "x"  values  in  the 
rectangular  coordinates  for  a  map  projection.  This  value 
frequently  is  assigned  to  eliminate  negative  numbers. 
Expressed  in  the  unit  of  measure  identified  in  Planar 
Coordinate  Units. 

Type:  real 

Domain:  False  Easting  >*  0.0 

False  Northing  -  the  value  added  to  all  "y"  values  in  the 
rectangular  coordinates  for  a  map  projection.  This  value 
frequently  is  assigned  to  eliminate  negative  numbers. 
Expressed  in  the  unit  of  measure  identified  in  Planar 
Coordinate  Units. 

Type:  real 

Domain:  False  Northing  >*  0.0 

Scale  Factor  at  Equator  -  a  multiplier  for  reducing  a 
distance  obtained  from  a  map  by  computation  or  scaling 
to  the  actual  distance  along  the  equator. 

Type:  real 

Domain.  Scale  Factor  at  Equator  >  0.0 
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2.3. 1.2. 1.2. 7 


2.3. 1.2. 1.2.8 


2.3. 1.2. 1.2.9 


2.3.1.2.1.2.10 


2.3.1.2.1.2.11 


2.3.1.2.1.2.11.1 


2.3.1.2.1.2.11.1.1 


2.3.1.2.1.2.11.1.2 


2.3.1.2.1.2.11.2 


2.3.1.2.1.2.12 


2.3.1.2.1.2.13 


Height  of  Perspective  Point  Above  Surface  —  height  of 
viewpoint  above  the  round  body,  expressed  in  meters 
Type:  real 

Domain:  Height  of  Perspective  Point  Above 
Surface  >  0  0 

Longitude  of  Projection  Center  —  longitude  of  the  point 
of  projection  for  azimuthal  projections 
Type:  compound 

Latitude  of  Projection  Center  --  latitude  of  the  point  of 
projection  for  azimuthal  projections. 

Type:  compound 

Scale  Factor  at  Center  Line  --  a  multiplier  for  reducing  a 
distance  obtained  from  a  map  by  computation  or  scaling 
to  the  actual  distance  along  the  center  line. 

Type:  real 

Jomain:  Scale  Factor  at  Center  Line  >  0  0 

Oblique  Line  Description  --  method  used  to  describe  the 
line  along  which  an  oblique  mercator  map  projection  is 
centered. 

Type:  .  compound 

Azimuthal  Description  --  description  of  the  center 
line  using  the  map  projection  origin  and  an 
azimuth. 

Type:  compound 

Azimuthal  Angle  -  angle  measured 
clockwise  from  north,  and  expressed  in 
degrees. 

Type:  real 

Domain:  0.0  <-  Azimuthal 
Angle  <  360.0 

Azimuth  Measure  Point  Longitude  - 
longitude  of  the  map  projection  origin. 
Type:  compound 

Two-Point  Description  -  two  points  near  the  limits 
of  the  mapped  region  that  define  the  center  line 
Type:  compound 

Straight  Vertical  Longitude  from  Pole  -  longitude  to  be 
oriented  straight  up  from  the  North  or  South  Pole. 

Type:  compound 

Scale  Factor  at  Projection  Origin  -  a  multiplier  for 
reducing  a  distance  obtained  from  a  map  by  computation 
or  scaling  to  the  actual  distance  at  the  projection  origin. 
Type:  real 

Domain.  Scale  Factor  at  Projection  Origin  >  0  0 
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2.3. 1.2. 1.2  14 


2.3.1.2.1.2.15 


2.3.1.2.1.2.16 


2.3. 1.2. 1.3 

2.3. 1.2.2 

2.3.1. 2.2.1 

2.3.1. 2.2.2 

2.3.1. 2.2.2. 1 

2.3.1. 2.2.3 

2.3.1.2.2.3.1 


Landsat  Number  --  number  of  the  Landsat  satellite 
Type:  Integer 

Domain:  0  <  Landsat  Number  <  5 

Path  Number  --  number  of  the  orbit  of  the  Landsat 
satellite. 

Type:  integer 

Domain.  0  <  Path  Number  <  251  for  Landsats  I. 
2.  or  3 

0  <  Path  Number  <  233  for  Landsats  4 
or  5 

Scale  Factor  at  Central  Meridian  -  a  multiplier  for 
reducing  a  distance  obtained  from  a  map  by  computation 
or  scaling  to  the  actual  distance  along  the  central 
meridian. 

Type:  real 

Domain:  Scale  Factor  at  Central  Meridian  >  0  0 

Map  Projection  Coordinate  Units  --  units  of  measure  used  for 
the  cartesian  coordinate  system. 

Type:  text 

Domain:  free  text  "Unknown”  "Not  applicable” 

Grid  Coordinate  System  --  a  plane-rectangular  coordinate  system 
usually  based  on,  and  mathematically  adjusted  to,  a  map  projection 
so  that  geographic  positions  can  be  readily  transformed  to  plane 
coordinates. 

Type:  compound 

Grid  Coordinate  System  Name  -  name  of  the  grid  coordinate 
system. 

Type:  text 

Domain:  "Universal  Transverse  Mercator" 

"Universal  Polar  Stereographic" 

"State  Plane  Coordinate  System  1927” 

"State  Plane  Coordinate  System  1983" 

Universal  Transverse  Mercator  -  a  grid  system  based  on  the 
transverse  mercator  projection,  applied  between  latitudes  84 
degrees  north  and  80  degrees  south  on  the  Earth’s  surface. 
Type:  compound 

UTM  Zone  Number  -  identifier  for  the  UTM  zone. 
Type:  integer 

Domain:  l  <“  UTM  Zone  Number  <-  60 

Universal  Polar  Stereographic  —  a  grid  system  based  on  the 
polar  stereographic  projection,  applied  to  the  Earth’s  polar 
regions  north  of  84  degrees  north  and  south  of  80  degrees 
south. 

Type:  compound 

UPS  Zone  Identifier  -  identifier  for  the  UPS  zone 
Type:  text 

Domain:  UPS  Zone  Identifier  -  [  "A"  i  "B"  "Y" 
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2.3  I. 2.2.4 


2.3.1. 2.2.4  I 


2.3. 1.2.2. 5 


2.3.1.2.2.5.1 


2.3.1.2.2.5.2 


2.3.1.2.2.5.2.1 


2.3.1.2.2.5.2.2 


2.3.1 22.52.3 


2.3.1.2.2.5.2.4 


2.3. 1.2.3 


State  Plane  Coordinate  System  --  a  plane-rectangular 
coordinate  system  established  by  the  National  Geodetic 
Survey,  one  for  each  state  in  the  United  States. 

Type.  compound 

SPCS  Zone  Identifier  -  identifier  for  the  SPCS  zone. 
Type:  text 

Domain,  valid  SPCS  zone  identifiers. 

Geodetic  Model  --  parameters  for  the  shape  of  the  earth  used 
for  the  map  projection  or  grid  system. 

Type:  compound 

Horizontal  Datum  Name  *-  the  identification  given  to  the 
reference  system  used  for  defining  the  coordinates  of 
points. 

Type:  text 

Domain:  free  text  "North  American  Datum  of 

1927"  "North  American  Datum  of  1983" 

Ellipsoid  --  a  mathematical  figure  generated  by  the 
revolution  of  the  ellipse  about  one  of  its  axes.  The 
ellipsoid  that  approximates  the  geoid  is  an  ellipse  rotated 
about  its  minor  axis. 

Type:  compound 

Ellipsoid  Name  --  identification  given  to 
established  representations  of  the  Earth's  shape. 
Type:  text 

Domain:  free  text  "Clarke  1866" 

"Geodetic  Reference  System  80" 

Semi-major  Axis  —  radius  of  the  equatorial  axis  of 
the  ellipsoid. 

Type:  real 

Domain:  Semi-major  Axis  >  0.0 

Denominator  of  Flattening  Ratio  -  the 
denominator  of  the  ratio  of  the  difference  between 
the  equatorial  and  polar  radii  of  the  ellipsoid  when 
the  numerator  is  set  to  I. 

Type:  real 

Domain:  Denominator  of  Flanening  >  0.0 

Semi-minor  Axis  —  radius  of  the  polar  axis  of  the 
ellipsoid. 

Type:  real 

Domain:  Semi-minor  Axis  >  0.0; 

Semi-minor  Axis  <  Semi-major 
Axis 

Local  Planar  -  any  right-handed  planar  coordinate  system  of  which 
the  z-axis  coincides  with  a  plumb  line  through  the  ongin  that 
locally  is  aligned  with  the  surface  of  the  Ea.’th. 

Type  compound 
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2.3. 1.2.3. I 


2.3. 1.2.3. 2 


2.3. 1.2.4 


2.3. 1.3 


2.3. 1.3.1 


2.3. 1.3.2 


2.3.2 


2.3 .2.1 


2.3.2. 1.1 


2.3.2. 1.2 


2.3.2 .2 


Local  Planar  Description  --  a  description  of  the  local  planar 
system  that  is  not  explicitly  linked  to  an  established  Earth 
reference  system. 

Type  text 

Domain:  free  text 

Planar  Georeference  Information  --  a  description  of  the 
information  provided  to  register  the  local  planar  system  to  the 
Earth  (e.g.  control  points,  satellite  ephemeral  data,  inertial 
navigation  data). 

Type:  text 

Domain:  free  text 

Planar  Distance  Units  -  units  of  measure  used  for  distances 
Type:  text 

Domain:  free  text  "meters"  "international  feet"  "survey  feet” 

Local  --  a  description  of  any  coordinate  system  that  is  not  aligned  with 
the  surface  of  the  Earth. 

Type.  compound 

Local  Description  -  a  description  of  the  coordinate  system  and  its 
orientation  to  the  surface  of  the  Earth. 

Type:  text 

Domain:  free  text 

Local  Georeference  Information  -  a  description  of  the  information 
provided  to  register  the  local  system  to  the  Earth  (e.g.  control 
points,  satellite  ephemeral  data,  inertial  navigation  data). 

Type.  text 

Domain:  free  text 

Vertical  Coordinate  System  Definition  ~  the  reference  frame  or  system 
from  which  vertical  distances  (elevations  or  depths)  are  measured 
Type:  compound 

Elevation  System  Definition  -  the  reference  frame  or  system  from 
which  elevations  are  measured. 

Type:  compound 

Elevation  Datum  Name  -  the  identification  given  to  the  level 
surface  taken  as  the  surface  of  reference  from  which 
elevations  are  measured. 

Type:  text 

Domain:  free  text  "National  Geodetic  Vertical  Datum 
of  1929"  "North  American  Vertical  Datum  of 
1988" 

Elevation  Distance  Units  -  units  in  which  elevations  are 
recorded 

Type:  text 

Domain:  free  text  "meters”  "feet" 

Depth  System  Definition  —  the  reference  frame  or  system  from 
which  elevations  are  measured. 

Type  compound 
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2.3 .2.2 


2.3.3 


2.3.3. 1 


2.3.3. 1.1 


2.3.3. 1.1 


Revised 


1  Depth  Datum  Name  --  the  identification  given  to  the  level 

surface  taken  as  the  surface  of  reference  from  which 
elevations  are  measured. 

Type:  text 

Domain:  Chart  datum:  datum  for  sounding  reduction " 

"Lowest  astronomical  tide" 

"Highest  astronomical  tide"  "Mean  low  water' 
"Mean  high  water"  "Mean  sea  level" 

"Land  survey  datum" 

"Mean  low  water  springs" 

"Mean  high  water  springs" 

"Mean  low  water  neap" 

"Mean  high  water  neap" 

"Mean  lower  low  water" 

"Mean  lower  low  water  springs" 

"Mean  higher  high  water" 

"Mean  higher  low  water" 

"Mean  lower  high  water"  "Spring  tide" 

"Tropic  lower  low  water”  "Neap  tide" 

"High  water”  "Higher  high  water" 

"Low  water"  "Low-water  datum" 

"Lowest  low  water"  "Lower  low  water” 
"Lowest  normal  low  water”  "Mean  tide  level" 
"Indian  spring  low  water” 

"High-water  lull  and  charge" 

"Low-water  full  and  charge" 

"Columbia  River  datum" 

"Gulf  Coast  tow  water  datum" 

"Equatorial  springs  low  water" 

"Approximate  lowest  astronomical  tide" 

"No  correction"  free  text 

Depth  Distance  Units  -  units  in  which  elevations  are 
recorded. 

Type:  text 

Domain:  free  text  "meters"  "feet" 

Point/Vector  Object  Information  -  means  of  encoding  locations  for,  and  t>pes 
and  numbers  of,  point  or  vector  spatial  objects  in  the  data  set. 

Type:  compound 

Point/Vector  Positional  Representation  -  means  of  encoding,  and 
resolution  of,  horizontal  and  vertical  coordinates  of  point  of  vector  spatial 
objects. 

Type:  compound 

Point/Vector  Horizontal  Position  -  means  of  encoding,  and  the 
resolution  of.  horizontal  coordinates  of  point  or  vector  spatial 
objects. 

Type:  compound 

.1  Point/Vector  Horizontal  Encoding  Method  --  the  means  used 

to  represent  the  horizontal  position  of  point  or  vector  spatial 
objects. 

Type:  text 

Domain:  "coordinate  pair"  "distance/bearing" 
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2.3.3. 1.1.2 


2.3.3  I  1.2.1 


2.3.3. 1. 1.2.2 


2.3.3. 1. 1.2.3 


2.3.3. 1.1.3 


2.3.3.I. 1.3.1 


2.3.3. 1.1.3 .2 


2.3  3.1. 1.3.3 


2.3.3.I. 1.3.4 


2.3.3. 1.1.4 


2.3.3. 1. 1.4.1 


Revised  Draft 


Coordinate  Pair  Representation  -  the  method  of  encoding  the 
position  of  a  point  by  measuring  its  distance  from 
perpendicular  reference  axes  (the  "coordinate  pair"  method) 
Type:  compound 

Abscissa  Resolution  --  the  minimum  distance  between 
the  x  or  longitude  values  of  two  adjacent  points, 
expressed  in  (ground)  meters  or  degrees. 

Type:  real 

Domain:  Abscissa  Resolution  >  0.0 

Ordinate  Resolution  --  the  minimum  distance  between 
the  y  or  latitude  values  of  two  adjacent  points, 
expressed  in  (ground)  meters  or  degrees. 

Type:  real 

Domain:  Ordinate  Resolution  >  0.0 

Coordinate  Pair  Resolution  Units  -*  the  units  of  measure 
in  which  the  Abscissa  Resolution  and  Ordinate 
Resolution  data  elements  are  expressed. 

Type:  text 

Domain:  "meters"  "degrees" 

Distance/Bearing  Representation  ~  a  method  of  encoding  the 
position  of  a  point  by  measuring  its  distance  and  direction 
(azimuth  angle)  from  another  point. 

Type:  compound 

Distance  Resolution,-  the  minimum  distance  measurable 
between  two  points,  expressed  in  (ground)  meters 
Type:  real 

Domain:  Distance  Resolution  >  0.0 

Bearing  Resolution  -  the  minimum  angle  measurable 
between  two  points,  expressed  in  degrees. 

Type:  real 

Domain:  Bearing  Resolution  >  0.0 

Bearing  Reference  Direction  -  direction  from  which  the 
bearing  is  measured. 

Type:  text 

Domain:  "North"  "South" 

Bearing  Reference  Meridian  -  axis  from  which  the 
bearing  is  measured. 

Type:  text 

Domain:  "Assumed”  "Grid"  "Magnetic" 
"Astronomic"  "Geodetic" 

Point/Vector  Vertical  Position  -  means  of  encoding,  and  the 
resolution  of,  elevations  of  point  or  vector  spatial  objects 
Type:  compound 


Point/Vector  Vertical  Encoding  Method  -  the  means 
used  to  encode  the  elevation  of  point  or  vector  spatial 
objects. 

Type:  text 
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23.3.2 

2.3. 3.2.1 

2.3 .3 .2.2 

2.3 .3 .3 

2.3.3.3.1 


2.3 .3.3.2 


Domain:  "Vertical  coordinate  included  with 
horizontal  coordinates"  "Attribute 
values" 

Point/Vector  Vertical  Resolution  --  the  minimum 
distance  between  two  adjacent  elevation  values, 
expressed  in  meters.  Used  when  elevation  is  expressed 
as  a  coordinate. 

Type:  real 

Domain:  Point  Vector  Vertical  Resolution  > 

0.0 

Point  Object  Information  -  types  and  numbers  of  point  spatial  objects  in 
the  data  set.  This  term  is  used  when  points  are  used  exclusively  in  the 
data  set. 

Type:  compound 

Point  Object  Type  -  name  of  point  spatial  objects  used  to  locate 
zero-dimensional  geometric  locations  in  the  data  set. 

Type:  text 

Domain:  "Point"  "Entity  point"  "Label  point"  "Area  point" 

Point  Object  Count  -  number  of  each  point  object  type  used  in  the 
data  set. 

Type:  integer 

Domain:  Point  Object  Count  >  0 

Vector  Object  Information  -  means  of  encoding  locations  and  types  and 
number  of  vector  spatial  objects  used  in  the  data  set. 

Type:  compound 

Vector  Object  Type  --  name  of  vector  spatial  objects  used  to  locate 
zero-,  one-,  or  two-dimensional  geometric  locations  in  the  data  set. 

Type:  text 

Domain:  "Point"  "Entity  point"  "Label  point"  "Area  point” 

"Node,  planar  graph"  "Node,  network"  "String" 
"Link"  "Complete  chain"  "Area  chain” 

"Network  chain,  planar  graph" 

"Network  chain,  nonplanar  graph" 

"Circular  arc,  three  point  center"  "Elliptical  arc" 
"Uniform  B-spline"  "Piecewise  Bezier" 

"Ring  with  mixed  composition" 

"Ring  composed  of  strings" 

"Ring  composed  of  chains" 

"Ring  composed  of  arcs"  "G-polygon" 

"GT-polygon  composed  of  rings" 

"GT-polygon  composed  of  chains" 

"Universe  polygon  composed  of  rings" 

"Universe  polygon  composed  of  chains” 

"Void  polygon  composed  of  rings" 

"Void  polygon  composed  of  chains” 

Vector  Object  Count  --  number  of  each  vector  object  type  used  in 
the  data  set 

Type  integer 

Domain  Vector  Object  Count  >  0 
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:.3.4 


2.3  4 1 


2.3  4.1.1 


2.3.4. 1.1. 1 


2.3.4. 1.1.2 


2.3.4. 1.1.3 


2.3 .4.2 


2. 3-4. 3 


2.34.3. 1 


2.34.3.2 


2.34.4 


Raster  Object  Information  --  means  of  encoding  locations  for.  and  types  and 
numbers,  of  raster  spatial  objects  in  the  data  set. 

Type:  compound 


Raster  Position  Representation  -  means  of  encoding,  and  resolution  of. 
horizontal  and  vertical  coordinates  of  raster  spatial  objects 
Type.  compound 


Raster  Horizontal  Position  --  means  of  encoding,  and  the  resolution 
of,  horizontal  coordinates  of  raster  spatial  objects 
Type:  compound 


Raster  Horizontal  Encoding  Method  --  the  means  used  to 
represent  the  horizontal  position  of  raster  spatial  objects 
Type:  text 

Domain:  "explicit  coordinate"  "implicit  coordinate" 

Row  Resolution  ~  the  distance  between  adjacent  rows, 
expressed  in  (ground)  meters  or  degrees. 

Type:  real 

Domain:  Row  Resolution  >  0.0  "varies" 


Column  Resolution  -  the  distance  between  adjacent  colutr 
expressed  in  (ground)  meters  or  degrees. 

Type:  real 

Domain:  Column  Resolution  >  0.0  "varies" 


Raster  Horizontal  Distance  Units  --  the  units  of  measure  in  which 
the  Row  Resolution  and  Column  Resolution  data  elements  are 
expressed. 

Type:  text 

Domain:  "meters”  "degrees" 

Raster  Vertical  Position  -  the  means  used  to  represent  and  the  resolution 
of  the  elevation  of  raster  spatial  objects. 

Type:  compound 

Raster  Vertical  Encoding  Method  ~  the  means  used  to  represent  the 
vertical  position  of  raster  spatial  objects. 

Type:  text 

Domain:  "Explicit  vertical  coordinates"  "Attribute  values" 
"Implicit  vertical  coordinates" 

Raster  Vertical  Resolution  -  the  minimum  distance  between  two 
adjacent  elevation  values,  expressed  in  meters.  Used  when 
elevation  is  expressed  as  a  coordinate  or  index. 

Type:  real 

Domain:  Raster  Vertical  Resolution  >  0.0 

Raster  Object  Type  --  raster  spatial  objects  used  to  locate  zero-or  two- 
dimensional  geometric  locations  in  the  data  set. 

Type:  text 

Domain:  "Point"  "Pixel"  "Grid  Cell"  "Voxel" 
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2.3.4. 5  Raster  Object  Count  --  number  of  spatial  objects  of  the  raster  obiect  t\pe 

used  in  the  data  set. 

Type:  integer 

Domain:  Raster  Object  Count  >  0; 

in  planar  cases. 

Raster  Object  Count  <=  Row  Count  *  Column 
Count; 

in  volumetric  cases. 

Raster  Object  Count  <=  Row  Count  *  Column 
Count  •  Depth  Count 

2.3.4  6  Row  Count  --  the  maximum  number  of  raster  objects  along  the  ordinate 

(y)  axis.  For  use  with  rectangular  raster  objects. 

Type:  Integer 
Domain;  Row  Count  >  0 

2.3.4. 7  Column  Count  -  the  maximum  number  of  raster  objects  alone  the 

abscissa  (x)  axis.  For  use  with  rectangular  raster  objects. 

Type:  Integer 

Domain:  Column  Count  >  0 

2.3  4.8  Depth  Count  -  the  maximum  number  of  raster  objects  along  the  depth  (z) 

axis.  For  use  with  rectangular  volumetric  raster  objects  (voxels) 

Type:  Integer 

Domain:  Depth  Count  >  0 


2.4  Spatial  Reference  Element  Context  Syntax; 

Spatial_Reference  = 

Native_Spatial_Data_Stracture  + 

[Indirect_Spatial_Reference  | 

Direct  Spatial  Reference  | 

Indirect_Spatial_Reference  + 

Direct_Spatial_Reference  ] 

Direct_Spatial_Reference  * 

Horizontal_Coordinate_System_Defmition  + 
(Vertical_Coordinate_System_Defmition)  + 
[Point/VectorObjectlnformation  | 

Raster_Object_Information] 

Horizon  tal_Coordinate_System_Definition  = 

[Geographic  I 
I  {Planar | n  | 

Local] 

Geographic  ■ 

Geographic,Coordinate_Units  + 

Geodetic_Model 

Planar  - 

[Map_Projection  I 

Gnd_Coordinate_System  | 

Local, Planar]  * 

Planar,  Distance_Units 
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Map_  Projection  = 
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MapProjectionName  ~ 
(AIbers_Conical_Equal_Area 
Azimuthal_Equtdistant 
EquidistantConic 
Equirectangular 

General_Vertical_Near-sided_Perspective 
Gnomonic  i 

Lambert_Azimutha!_Equal_Area  ; 
Lambert_Conformal_Conic  | 

Mercator  I 

Modified_Stereographic_for_Alaska  I 
MiUer_Cylindrical  | 

ObliqueMercator  | 

Orthographic  | 

Polar_Stereographic  | 

Polyconic  I 
Robinson  | 

Sinusoidal  ! 

Space_Oblique_Mercator  | 

Stereographic  | 

Transverse  Mercator  | 
van_der_GrintenJ  + 

Geodetic_Model 

Albers_Conical_Equal_Area  * 

1  {Standard_Parallel}2  + 
Longitude_of_Central_Meridian  + 

Latitude j)f_Projection_Origin  + 

False_Easting 

False_Northing 

Azimuthal  Equidistant  * 

Longitude_ofCentral_Meridian  + 
LatitudeofProjectionOngin  + 
FalseEasting  + 

False_Northing 

Equidistant_Conic  * 

I  {Standard_Parallel}2  + 
Longitude_of_Central_Meridian  + 
Latinjde_of_Projection_Origin  + 
FalseEasting  + 

False_Northing 

Equirectangular  * 

Standard  Parallel 

Longitude_of_Central_Meridian  ■+■ 

False  Easting  ♦ 

False_Northing 

General_Vertical_Near-sided_Perspective  * 

Height_of_Perspective_Point_Above_Surface 
Longitude _of_Projection_Center  * 
Latitude_of_Projection_Center  + 
False_Easting  + 

False_Northing 
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Gnomonic  = 

LongitudeofProjectionCenter  » 
LatitudeofProjectionCenter  * 
FalseEasting  ♦ 

FalseNorthing 

Lambert_Azimuthal_£qual_Area  = 

Longitude  of  Projection  Center  - 
Latitude_of_Projection_Center  - 
False_Easting  * 

False_Northing 

Lambert_Conformal_Conic  = 

I  { Standard_  Paral  lei }  2  + 
Longitude_of_Central_Meridian  - 
Latitude_of_Projection_Origin  + 
False  Easting 
False_Northing 


Mercator  = 

[Standard  Parallel  | 

Scale_Factor_at_Equator)  + 
Longitude_of_Centrai_Meridian  + 
FalseEasting  + 

FalseNorthing 

Modified_Stereographic_for_Alaska  * 

FalseEasting  + 

False  Northing 

MillerCylindrical  * 

LongitudeofCentralMeridian  + 
FalseEasting  + 

False^Northing 

Oblique  Mercator  * 

Scale_Factor_at_Center_Line  *■ 
Oblique_Line_Description  + 
Latitude_of_Projection_Origin  + 
FalseEasting  + 

FalseNorthing 

Oblique_Line_Description  » 

[Azimuthal  Description  | 

Two-  PointDescription] 

Azimuthal_Description  ■ 

Azimuthal  _  Angle  + 
Azimuth_Measure_Point_Longitude 

Azimuth_Measure_Point_Longitude  - 
Longitude 

Two-Point_Description  * 

2 (Latitude  » 

Longitude)  2 


Orthographic  = 


674 


Longitude_of_Projection_Center  - 
Latitude_of_Projection_Center  - 
Fa!se_Hasting  - 
FalseNorthing 

Polar_Stereographic  = 

Straight-Vertical  Longitude  from  Pole 
[Standard_Parallel 

Scale_Factor_at_Projection_Origin] 

False_Easting  + 

False_Northing 

Straight-Vertical_Longitude_from_Pole  = 

Longitude 

Polyconic  = 

Longitude_of_Central_Meridian  * 

Latitude_of_Projection_Origin 

FalseEasting 

False_Northing 

Robinson  = 

Longitude_of_Projection_Center  + 
FalseEasting  + 

False_Northing 

Sinusoidal  ■ 

Longitude_of_Central_Meridian  + 
FalseEasting  + 

FalseNorthing 

Space_Oblique_Mercator  ■ 

LandsatNumber  + 

PathNumber  + 

False  Easting 
FalseNorthing 

Stereographic  * 

Longitude_of_Projection_Center  + 
Latitude_of_Projection_Center  + 
FalseEasting  + 

FalseNorthing 

Transverse  Mercator  « 

Scale_Factor_at_CentraI_Meridian  + 
Longitude_of_Central_Meridian  + 
LatitudeofProjectionOrigin  + 
FalseEasting  + 

False_Nonhing 

van_der_Grinten  - 

Longitude_of_Central_Meridian  +■ 

False  Easting 
FalseNorthing 
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Standard_  Parallel  = 

Latitude 

Longitude  of  Central  Meridian  = 

Longitude 

Latitude  of  Projection  Origin  = 

Latitude 

Longitude  of  Projection  Center  = 

Longitude 

Latitude  of  Projection  Center  = 

Latitude 

Grid_Coordinate_System  = 

Grid_Coordinate_SystemNante  + 
[Univer$al_Transverse_Mercator  | 
UniversalPolarStereographic  | 
StatePlaneCoordinateSystem]  + 
GeodeticModel 

Universal_Tnmsverse_Mercator  * 

LfTMZoneNumber  + 

T  rans  verseMercator 

Universal  Pola'  Stereographic  * 

UPS_Zone_Identifier  + 
Polar_Stereographic 

StatePlaneCoordinateSystem  - 

SPCS_Zone_Identifier  + 

[Lambert  Conformal  Conic  | 
Transverse_ Mercator  | 
ObliqueMercator  | 

Poiyconic] 


Geodetic  Model  *> 

(Hori2ontal_Datum_Name)  + 
Ellipsoid 

Ellipsoid  ” 

EIIipsoid_Name  + 

Semi-majorAxis  *■ 

[  Denominator_of_Flattening_Ratio  | 
Semi-minor_Axis  ] 

Local_Planar  - 

Local -Planar-Description  + 

Plan  arGeo  reference-information 

Local  - 

Local-Description  + 

Local  _Georeference_lnfonnation 

Vertical_Coordinate_System_Definition  * 

(Elevation  System-Definition)  + 
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(DepthSystemDefinition) 


Eleiation_System_Defmition  = 

ElevationDatumName  * 
Elevation_Distance_Umts 

DepthSystemDefinition  = 

Depth_Darum_Name  ♦ 

Depth_Distance_Units 

Point.  VectorObjectlnformation  = 

Point/Vector_Position_Representation  * 

( [Poim_Object_information  | 

V ectorObject -Information]  ) 

Point/Vector_Position_Representation  = 

Point/Vector_Horizontal_Position 
( Point/V  ector_  VerticaI_Position) 

Point/Vector_Horizontal_Position  = 

Point/Vector_HorizontaI_Encoding_Method  + 
(  [Coordinate_Pair_Representation  j 
Distance/Bearing_ Representation]  ) 

Coordinate_Pair_Representation  * 

Abscissa_Resolution  + 

Ordinate_Re$oIution  + 
CoordinatePairResolutionUnits 

Distance/BearingRepresentation  * 

Distance_Resolution 
BeanngResolution  + 
BeanngReferenceDirection  + 
Bearing_Reference_Meridian 

Point/Vector_Vertical_Position  * 

Po  int/V  ector_  V  ertical_Encoding_Method  + 
(Point/V  ector_V  erticalResolution) 

Point_Object_Information  * 

1{  Point_Object_Type  + 

(Point_Object_Count)  }n 

VectorObjectlnformation  = 

1{  Vector_Object_Type  + 
(Vector_Object_Count)  }n 

Raster  Object  lnformation  ■ 

RasterPositionRepresentation  + 
RasterObjectType  + 

(Raster  Object  Count)  + 

(Row  Count  * 

Column_Count  + 

(DepthCount)  ) 


Raster  Position  Representation  * 

Raster  Horizontal-Position  +■ 

:6 
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(Raster  Vertical  Position) 

Raster_Honzontal_Position  = 

Raster_Horizontal_Encoding_Method  - 
(Row_Resolution  * 

Column  Resolution  * 
Raster_Horizontal_Distance_Units) 

Raster_Vertical_Position  = 

Raster_  Vertical_Encoding_Method  - 
(RasterVerticalResolution) 
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Status  Information 


3  Status  Information  --  the  state,  release,  and  update  information  for  the  data  set. 

Type:  compound 

3  I  Data  Set  Status  --  the  state  of  the  data  set. 

Type.  text 

Domain:  "Available"  "In  work"  "Planned" 

3.2  Release  Date  --  the  date  by  which  the  data  set  is  available  for  release. 

Type:  date 

Domain,  free  date  "Unknown” 

3.3  Maintenance  and  Update  Frequency  —  the  frequency  in  days  with  which  changes  and 
additions  are  made  to  the  data  set  after  the  initial  data  set. 

Type:  real 

Domain:  Maintenance  and  Update  Frequency  >  0.0  "Not  applicable" 

"Unknown"  "As  needed"  "Irregular" 

3.4  Status  Information  Element  Context  Syntax: 

Statuslnformation  = 

Data_Set_Status  J- 
Release_Date  + 

Maintenance_and_Update_Frequency 
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Source  Information 


4  Source  Information  -  list  of  sources  and  a  short  discussion  of  the  information  contributed 

b>  each. 

Type:  compound 

4  1  Source  Identity  --  identity  of  a  source  data  set 

Type:  compound 

4  2  Source  Contribution  -  brief  statement  identifying  the  information  contributed  bv  the 

source  to  the  data  set. 

Type.  text 

Domain,  free  text 

4-3  Source  Information  Element  Context  Syntax: 


Sourcejnformation  = 


Sourcejdentity  * 

Source_C  ontribution 
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Processing  History  Information 

Processing  History  Information  --  information  about  the  events,  parameters,  and  source  data 
which  constructed  the  data  set.  and  information  about  the  responsible  parties 
Type  compound 

Process  Step  --  information  about  a  single  event. 

Type:  compound 

Process  Description  --  an  explanation  of  an  event  and  related  parameters  or 
tolerances. 

Type:  text 

Domain,  free  text 

Process  Date  --  the  date  when  the  event  was  completed. 

Type:  date 

Domain:  free  date  "Unknown"  "Not  complete" 

Process  Time  --  the  time  when  the  event  was  completed. 

Type:  time 

Domain:  free  time 

Source  Identity  --  identity  of  a  source  data  set. 

Type:  compound 

Process  Contact  -  the  party  responsible  for  the  metadata  information. 

Type:  compound 

Processing  History  Information  Element  Context  Syntax: 


Processing_History_Infc  ,-mation 


I  {Process_Step}n 


ProcessStep 


Process_Description  + 
ProcessDate  + 
(Process_Time)  + 
0{Source_Identity}n  + 
(ProcessContact) 


Process  Contact 


Contact  Information 
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Entity  Attribute  Information 

6  Entity  Attribute  Information  --  information  about  the  entities  types,  their  attributes,  and  the 

domains  from  which  attribute  values  may  be  assigned  that  occur  in  the  data  set 
Type  compound 

6  I  Entity  Type  --  The  definition  and  description  of  a  set  into  which  similar  entitv 

instances  are  classified. 

Type:  compound 

6.1.1  Entity  Type  Label  -  the  name  of  the  entity  type. 

Type:  text 

Domain:  free  text 

6.1.2  Entity  Type  Definition  -•  the  description  of  the  entity  type 

Type:  text 

Domain:  free  text 

6. 1 .3  Entity  Type  Definition  Source  ~  the  authority  of  the  definition. 

Type:  text 

Domain:  free  text 

6.2  Attribute  ••  A  defined  characteristic. 

Type:  compound 

6.2.1  Attribute  Label  ~  the  name  of  the  attribute. 

Type:  text 

Domain:  free  text 

6.2.2  Attribute  Definition  -  the  description  of  the  attribute. 

Type:  text 

Domain:  free  text 

6.2.3  Attribute  Definition  Source  -  the  authority  of  the  definition. 

Type:  text 

Domain:  free  text 

Attribute/Entity  Association  --  information  about  the  values  of  the  attribute  of  an 
entity  type. 

Type:  compound 

EA  Domain  Values  -  the  valid  values. 

Type:  compound 

Enumerated  Domain  ••  the  members  of  an  established  set  of  valid  values. 
Type:  compound 

Enumerated  Domain  Value  -  the  name  or  label  of  a  member  of  the 
set. 

Type  text 

Domain  free  text 

6.3. 1.1.2  EDV  Definition  -•  the  description  of  the  value. 

Type  text 

Domain  free  text 


6.3 

6.3.1 

6.3. 1.1 

6.3. 1.1.1 
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6  3  1  1.3 


6  3  12 


63.1.2.1 


63.1.2.2 


6.3. 1.3 


6.3. 1.3.1 


6.3. 1.3.2 


6.3. 1.4 


6.3.2 


6.3.3 


6.3.4 


6.3.5 


EDV  Definition  Source  --  the  authority  of  the  definition 
Type  text 
Domain:  free  text 


Range  Domain  --  the  minimum  and  maximum  values  of  a  continuum  of 
valid  values 

Type:  compound 


Range  Domain 
assigned. 

Type: 

Domain: 


Minimum  --  the  least  value  that  the  annbute  can  be 
text 

free  text 


Range  Domain 
be  assigned. 
Type: 
Domain: 


Maximum  --  the  greatest  value  that  the  annbute  can 
text 

free  text 


Codeset  Domain  -  reference  to  a  standard  or  list  which  contains  the 
members  of  an  established  set  of  valid  values. 

Type:  compound 

Codeset  Name  --  the  title  of  the  codeset. 

Type:  text 

Domain:  free  text 

Codeset  Source  -  the  authority  for  the  codeset. 

Type:  text 

Domain:  free  text 

Unrepresentable  Domain  -  description  of  the  values  and  reasons  why 
they  cannot  be  represented. 

Type:  text 

Domain:  free  text 

EA  Units  of  Measurement  -  the  standard  of  measurement  associated  with  an 
attribute  value. 

Type:  text 

Domain:  free  text 

EA  Measurement  Precision  -  the  smallest  unit  increment  to  which  an  attribute 
value  is  measured. 

Type:  real 

Domain:  EA  Measurement  Precision  >  0.0 

EA  Beginning  Date  -  earliest  or  only  date  for  which  the  attribute  values  are 
valid.  In  cases  when  a  range  of  dates  are  provided,  this  is  the  earliest  date  tor 
which  the  information  are  valid. 

Type:  date 

Domain:  free  date 

EA  Ending  Date  --  latest  date  for  which  the  information  are  valid.  Used  in 
cases  when  a  range  of  dates  are  provided. 

Type:  date 

Domain:  free  date 
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6.3  6  EA  Accuracy  Information  --  an  assessment  of  the  certainty  of  the  assignment  of 

attribute  values 

Type:  compound 

EA  Accuracy  -  an  estimate  of  the  certainty  of  the  assignment  of  attribute 
values. 

Type  real 

EA  Accuracy  Explanation  --  the  definition  of  the  EA  Accuracy  measure 
and  units,  and  a  description  of  how  the  estimate  was  derived 
Type:  text 

Domain:  free  text 

6  3  7  EA  Measurement  Frequency  -  the  frequency  in  days  with  which  attribute 

values  are  added. 

Type:  real 

Domain:  Maintenance  and  Update  Frequency>  0.0  "Unknown"  "As 

needed"  "Irregular" 

6  4  Entiry/Attribute  Information  Element  Context  Syntax: 

Entity/Attribute_lnformation  = 

l{Entiry_Type  + 

Attribute  ▼ 

Entity  I  Atmbute_Association }  n 

Entity_Type  * 

Entity_Type_Label  + 

Entity  _Type_Definition  + 

EntiryTypeDefinitionSource 

Attribute  = 

Attribute_Label  + 

Attribute_Definition  + 

Attribute_Definition_Souree 


6.3  6  1 


6  3.6.2 


Entity/Attribute_ Association  * 

EA  _Dotnain_Values  + 
(EA_Units_of_Measure)  + 
(EA_Measurement_Precision)  + 
(EA_Beginning_Date  + 
(EA_Ending_Date)  )  + 
(EA_Accuracy_Information)  + 
(EA_Measurement_Frequency) 

EA_Domain_Values  - 

[Enumerited  Domain  | 
RangeDomain  | 

Codeset  Domain  | 

Unrep  resen  table_Domain] 

Enumerated_Domain  - 

I  {Enumerated_Domain_Value  + 
EDV  Definition  ♦ 
EDV_Definition_Source)n 
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Range_  Domain  = 

Range_Domain_Minimum  * 
RangeDomainMaximum 

Codeset_Domain= 

CodesetName  - 
Codeset_Source 

EAAccuracyJnformation  = 

EA  Accuracy  ♦ 
EAAccuracyExpIanation 
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Distribution  Information 

7  Distribution  Information  --  information  about  the  distributor  of  and  options  for  obtaining 

the  data  set. 

Type:  compound 

7.1  Distribution  Contact  --  the  party  from  whom  the  data  set  may  be  obtained 

Type:  compound 

7.2  Distribution  Liability  --  statement  of  the  liability  assumed  by  the  distributor 

Type:  text 

Domain:  free  text 

7.3  Transfer  Options  --  the  ways  in  which  the  data  set  may  be  obtained  or  received,  and 
related  instructions  and  fee  information. 

Type:  compound 

7  3  1  Media  -  the  forms  in  which  the  data  set  may  be  obtained  or  received. 

Type:  compound 

7  3  11  Non-digitaJ  media  -  the  description  of  option  for  obtaining  or  receiving 

the  data  set  on  non-computer-compatible  media. 

Type:  text 

Domain:  free  text 

7.3. 1.2  Digital  media  -  the  description  of  options  for  obtaining  or  receiving  the 

data  set  on  computer-compatible  media. 

Type:  compound 

7.3. 1.2.1  Transfer  Format  -  the  name  and  version  number  of  data  transfer 

format. 

Type:  text 

Domain: 

Domain 

Velwe  PefumiPQ 

"ADRG"  ARC  Digitized  Raster  Graphic 
"ADRI"  ARC  Digitized  Raster  Imagery 
"ARCE5"  ARC/INFO  Export  format,  version  5 
"ARCE6"  ARC/INFO  Export  format,  version  6 
''ASCII"  ASCII  file,  formatted  for  text  attributes, 
declared  format 

"BIL"  Imagery,  band  interleaved  by  line 
"BIP"  Imagery,  band  interleaved  by  pixel 
"COORD"  User-created  coordinate  file,  declared 

format 

"DEM"  U.S.  Geological  Survey  Digital  Elevation 
Model  format 

"DFAD”  Digital  Feature  Analysis  Data 
"DGSTA"  Digital  Geographic  Information 

Exchange  Standard  (DIGEST)  Annex  A 
-  ISO  S21 1  form 

"DLGO"  U.S.  Geological  Survey  Digital  Line  Graph- 
Optional  format 

"DLGS"  U.S.  Geological  Survey  Digital  Line  Graph- 
Standard  format 

to 
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7.3. 1.2.2 


7.3.1. 2.2.1 


7.31. 2.2.2 


7.3. 1.2.3 


“DIED" 

"DXF9" 

"DXF10" 

-DXFU" 

"ERD73" 

"ERD74" 

"GRAS3” 

"GRAS4" 

"IGDS" 

“1GES" 

"MOSS" 

"NITF" 

"SDTSR" 

"SDTSV” 

"S1F” 

"SLF" 

“TIFF" 

’TIGRP" 


"TIGRC" 

"VPF" 


Digital  Terrain  Elevation  Data  (MIL-D- 
89020) 

AutoCAD  Drawing  Exchange  Format,  version 

9 

AutoCAD  Drawing  Exchange  Format,  version 

10 

AutoCAD  Drawing  Exchange  Format,  version 
II 

ERDAS  image  files,  version  7.3 
ERJDAS  image  files,  version  7.4 
Geographic  Resources  Analysis  Support 
System,  version  3 

Geographic  Resources  Analysis  Support 
System,  version  4 

Interactive  Graphic  Design  System  format 
(Intergraph  Corporation) 

Initial  Graphics  Exchange  Standard 
Multiple  Overlay  Statistical  System  export  file 
National  Imagery  Transfer  Format 
Spatial  Data  Transfer  Standard  raster  profile 
Spatial  Data  Transfer  Standard  topological 
vector  profile 

Standard  interchange  Format  (DOD  Project 
2851) 

Standard  Linear  Format 
Tagged  Image  File  Format 
Topologically  Integrated  Geographic 
Encoding  and  Referencing  System,  pre-census 
version 

Topologically  Integrated  Geographic 
Encoding  and  Referencing  System,  census 
version 

Vector  Product  Format  (MIL-STD-600006) 
(also  known  as  Digital  Geographic 
Information  Exchange  Standard  (DIGEST) 
Annex  C  -  Vector  Relational  form,  and 
Vector  Relational  Format) 


Transfer  Size  Information  -  information  on  file  compression 
techniques  applied  to  the  transferred  data  set  and  the  size  of  the 
resulting  file  sent  from  the  distributor. 

Type:  compound 

File  Compression  Technique  —  information  on  algorithms  or 
processes  applied  to  the  data  set  in  its  transfer  format  to 
reduce  the  size  of  the  file. 

Type:  text 

Domain:  free  text  "None" 

Transfer  Size  -  the  size  in  megabytes  of  transferred  data  set 
Type:  real 

Domain:  Transfer  Size  >  0.0 

Digital  Transfer  Options  —  the  means  and  media  by  which  a  data 
set  is  sent  from  the  distributor. 

Type  compound 
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7.3. 1.2.3  1  Online  Options  --  information  required  to  obtain  the  data  set 

electronically. 

Type:  compound 

'  3  1,2.3  I  I  Computer  Contact  Information  -  instructions  for 

establishing  communications  with  the  distribution 
computer. 

Type:  compound 

7. 3. 1.2. 3. 1.1  I  Network  Address  --  the  electronic  address  of  the 

distribution  computer. 

Type:  text 

Domain,  free  text 

7.3. 1.2.3. 1.2  Dialup  Instructions  --  information  required  to 

access  the  distribution  computer  remotely  through 
telephone  lines. 

Type:  compound 

7. 3. 1.2.3. 1.2.1  Lowest  BPS  -  lowest  or  only  speed  for  the 

connection’s  communication,  expressed  in  bits 
per  second. 

Type:  integer 

Domain:  Lowest  BPS  =  [  1 10  300 
600  |  1200  |  2400  |  4800 
9600  |  14400  ;  19200  I 
38400  |  57600  |  1 15200] 

7.3. 1.2.3. 1.2.2  Highest  BPS  ~  highest  speed  for  the 

connection’s  communication,  expressed  in  bits 
per  second.  Used  in  cases  when  a  range  of 
dates  are  provided. 

Type:  integer 

Domain:  Highest  BPS  *  [  300  :  600 
1200  |  2400  |  4800  !  9600 
14400  |  19200  |  38400 
57600  |  115200  J; 

Highest  BPS  >  Lowest  BPS 

7.3. 1 .2.3. 1 22.3  Number  DataSits  —  number  of  data  bits  in 

each  character  exchanged  in  the 
communication. 

Type:  integer 

Domain:  DataBits  “  [7  |  8] 

7.3. 1. 2.3. 1.2.4  Number  StopBits  —  number  of  stop  bits  in 

each  character  exchanged  in  the 
communication. 

Type:  integer 

Domain:  StopBits  *  [1  I  2] 

7.3. 1.2.3. 1.2.5  Parity  -  parity  error  checking  used  in  each 

character  exchanged  in  the  communication 

Type:  text 

Domain:  "None"  "Odd"  "Even" 

"Mark"  "Space" 
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7.3  1.2.3  1  2  6 

Dialup  Telephone  --  the  telephone  number  of 
the  distribution  computer 

Type:  text 

7.3  1 .2.3.1  3 

Access  Instructions  --  information  on  how  to  proceed 
once  the  connection  to  the  distribution  computer  is 
established. 

Type:  compound 

7.3. 1.2.3. 1.3.1 

Access  instruction  Text  --  instructions  on  the  steps 
required  to  access  the  data  set. 

Type:  text 

Domain:  free  text 

7.3. 1.2.3. 1.3.2 

Online  File  Name  --  the  identity  of  the  computer 
file  that  contains  all  or  part  of  the  data  set  on  the 
distribution  computer. 

Type:  text 

Domain:  free  text 

7.3. 1.2.3. 1.3.3 

Online  Computer  and  Operating  System  -  the  brand  of 
distribution  computer  and  its  operating  system. 

Type:  text 

Domain:  free  text 

7.3. 1.2.3. 1.4 

Offline  Options  -  information  about  media-specific  options 
for  receiving  the  data  set. 

Type:  compound 

7.3. 1.2.3. 1.4.1 

Cartridge  Tape  Options  -  information  describing  options 
for  data  sets  distributed  on  cartridge  tape. 

Type:  compound 

7.3. 1.2.3. 1.4. 1.1 

Cartridge  Type  -  identification  about  the  physical 

characteristics  of  the  cartridge. 
Type:  text 

Domain: 


Domain 

Value  Definition 

"QIC"  quarter-inch 

"4mm"  4  millimeter 

"8mm"  8  millimeter 

7.3. 1.2.3. 1. 4. 1.2  Cartridge  Formatted  Capacity  -  the  maximum 

amount  of  data,  in  megabytes,  that  can  be  written 
to  the  cartridge. 

Type:  real 

Domain:  Cartridge  Formatted  Capacity  > 

0.0 

7. 3. 1.2  3. 1.4. 1.3  Cartridge  Recording  Format  —  the  method  used  to 

write  the  data  set  to  the  cartridge. 

Type:  text 

Domain:  free  text  "cpio"  "tar" 
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7  3  1.2.3  !  4.1  4 


7  3  1  2.3  1 .4  2 


73.1.2.3.1.4.2.1 


73.1.2.3.1.4.2.2 


7.3.1.23.1.4.2.3 


73. 1. 2.3.  t. 4 .2.4 


7.3.1.23.1.4.3 


73.1.2.3.1.4.3.1 


Cartridge  Computer  and  Operating  System  -*  the 
brand  of  distribution  computer  and  its  operating 
system. 

T>pe  text 

Domain  free  text 

9-Track  Reel  Tape  Options  -  information  describing  options 
for  data  sets  distributed  on  half-inch,  9-track  tape  reels 
Type:  compound 

9-Track  Recording  Density  --  the  density,  in  byres  or 
characters  per  inch,  in  which  the  data  set  can  be 
recorded. 

Type:  integer 

Domain:  9-Track  Tape  Reel  Density  =  [800 
1600  |  6250] 

Record  Length  and  Block  Length  Information  - 
information  about  the  record  length  and  options  for 
block  size  in  which  the  data  set  can  be  recorded. 

Type:  text 

Domain:  free  text 

9-Track  Recording  Format  --  the  method  used  to  write 
the  data  set  to  the  cartridge,  including  information  about 
file  labels. 

Type:  text 

Domain:  free  text 

9-Track  Computer  and  Operating  System  -  the  brand  of 
distribution  computer  and  its  operating  system. 

Type:  text 

Domain:  free  text 

Floppy  Disk  Tape  Options  -  information  describing  options 
for  data  sets  distributed  on  floppy  disk. 

Type:  compound 

FD  Type  -  identification  about  the  physical 
characteristics  of  the  floppy  disk. 

Type:  text 

Domain: 


Domain 

mu 

Definition 

"525" 

Five  and  one- 

"3.5" 

quarter  inch 
Three  and  one- 

half  inch 

FD  Formatted  Capacity  -  the  maximum  amount  of  data, 
in  megabytes,  that  can  be  written  to  the  floppy  disk 
Type:  real 

Domain:  Floppy  Disk  Formatted  Capacity  - 
[  0.36  |  0.72  |  12  I  1.44  J 


4  5 
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.4  3  4 


7.3. 1.2.3. 1.4.4 


7.4 


7.5 


7.6 


7.7 


FD  Recording  Format  --  the  method  used  to  write  the 
data  set  to  the  floppy  disk. 

Type:  text 

Domain:  free  text 

FD  Computer  and  OS  Compatibility  -  the  brand  of 
computer(s)  and  operating  svstem(s)  with  which  the 
floppy  disk  is  compatible. 

Type:  text 

Domain:  free  text 


CD-ROM  Format  --  the  standard  followed  in  recording  the 
CD-ROM 

Type:  text 

Domain:  "High  Sierra"  "ISO  9660” 

"ISO  9660  with  Rock  Ridge  extensions" 


Transfer  Instructions  --  general  instructions  and  advise  about,  and  special  terms  and 
services  provided  for.  the  data  set  by  the  distributor. 

Type:  text 

Domain:  free  text 

Fees  -  the  fees  and  terms  for  retrieving  the  data  set. 

Type:  text 

Domain:  free  text 

Turnaround  -  typical  turnaround  time,  in  days,  for  the  filling  of  an  order. 

Type:  integer 

Domain:  Turnaround  >=  0 

Distribution  Information  Element  Context  Syntax: 


Distributionjnformation  = 


Distribution_Contact  * 
Transfer_Options  - 


Media  * 


Digital_Media  * 


1  (Distribution_Contact  * 
Distribution_Liability  + 

1  {Transfer_6ptions}n  }n 


Contactjnformation 


Media  * 

Transferjnstructions  + 
Fees  * 

(Turnaround) 


(Non-digital_Media  I 
DigitalMedia] 


Transfer_Format  + 
l(Transfer_Size_Information}n  + 
I  ( Digual_T  ransfer_Options)n 
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TransferSizelnfomiation  = 

FileCompressionlnformatton  * 
(Transfer_Size) 


Digital_Transfer_Opttons  = 

{Online_Options  , 
OfflineOptions] 


Online_Options  = 

1  (Computer_Contact_lnformation}n  - 

Accessjnsmicttons  - 

On  I  ine_C  omputer_and_Operating_Sy  stem 

Computer_Contact_Infonnation  = 

[Network_  Address  | 

Dialuplnsmictions] 

Dialup  lnstructions  * 

Lowest  BPS  + 

(Highest_BPS)  + 

Number^DataBits  +• 

Number_StopBits  + 

Parity  ♦ 

1  {Dialup_Telephone}n 

Accesslnstructions  = 

Access_Instmctions_Text  + 

(  1  {Online_File_Name}n  ) 


Offline_Options  * 

[Cartridge_Tape_Options  | 

9-Track_Reel_Tape_Options  | 

Floppy _Disk_Options  | 

CD-ROM_Fonnat] 

Cartridge  Tape  Options  * 

1  {Cartridge_Type  + 

Cartndge_Formatted_Capacity}n  + 
Cartridge_Recording_Fomutt  + 

Cartndge_C  omputer_and_Operating_System 

9-Track_Reel_Tape_Options  - 

1  {9_Track_Recording_Density}3  + 
Record_Length_and_Block_Length_Infomution  + 
9-Track_Recording_Fonnat  +• 

9-Track_C  omputerandOperatingSystem 

Floppy  Disk  Options  = 

HFD.Type  * 

FD_Fonnaned_Caparity)n  +• 
FD_Recording_Fonnat  + 
FD_Computer_and_OS_Comp«tibtHty 
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Metadata  Reference  information 

8  Metadata  Reference  Information  --  information  on  the  currentness  of  the  metadata 

information,  and  the  responsible  pam 

8  I  Metadata  Date  -  the  date  that  the  metadata  were  created  or  last  updated 

Type:  date 

Domain:  free  date 

8  2  Metadata  Review  Date  --  the  date  of  the  latest  review  of  the  metadata  entry 

Type:  date 

Domain:  free  date;  Metadata  Review  Date  later  than  Metadata  Date 

8.3  Metadata  Future  Review  Date  ~  the  date  by  which  the  metadata  entry  should  be 

reviewed. 

Type:  date 

Domain:  free  date;  Metadata  Future  Review  Date  later  than  Metadata  Review 

Date 


8.4  Metadata  Contact  -•  the  parry  responsible  for  the  metadata  information. 

Type:  compound 

8.3  Metadata  Reference  Information  Element  Context  Syntax: 

Metadata_Reference_Information  * 

Metadata^Date  + 

(  Metadata  Review  Date  + 

(Metadata JFuture  Review  Date)  )  + 
(Metadata.Contact) 


Metadata  Contact  - 


Contactlnformation 
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•  Contact  Information 

9  Contact  Information  --  Identity  of.  and  means  to  communicate  with,  person(s)  and.  or 

orgamzation(s)  associated  with  the  data  set. 

Type:  compound 

9  1  Contact  Person  Primary  --  the  person,  and  the  affiliation  of  the  person,  associated 

with  the  data  set  Used  in  cases  where  the  association  of  the  person  with  the  data  set 
is  more  significant  than  the  association  of  the  organization  with  the  data  set 
Type:  compound 

9.1.1  Contact  Organization  -  the  name  of  the  organization  to  which  the  contact  type 

applies. 

Type:  text 

Domain:  free  text 

9.1.2  Contact  Person  --  the  name  of  the  individual  to  which  the  contact  type  applies 

Type:  text 

Domain:  free  text 

9.2  Contact  Organization  Primary  --  the  organization,  and  the  member  of  the 
organization,  associated  with  the  data  set.  Used  in  cases  where  the  association  of  the 
organization  with  the  data  set  is  more  significant  than  the  association  of  the  person 
with  the  data  set. 

Type:  compound 

9.3  Contact  Position  -  the  title  of  individual  to  which  the  contact  type  applies. 

Type:  text 

Domain:  free  text 

9.4  Contact  Mail  Address  ••  the  address  of  organization  or  individual  to  which  the 
contact  type  applies. 

Type:  text 

Domain:  free  text 

9.5  Contact  Voice  Telephone  -  the  telephone  number  of  the  organization  or  individual  to 
which  the  contact  type  applies 

Type:  text 

Domain:  free  text 

9.6  Contact  Facsimile  Telephone  -  the  telephone  number  of  a  facsimile  machine  of  the 
organization  or  individual  to  which  the  contact  type  applies. 

Type:  text 

Domain:  free  text 

9.7  Contact  Electronic  Mail  Address  ~  the  address  of  the  electronic  mailbox  of  the 
organization  or  individual  to  which  the  contact  type  applies. 

Type:  text 

Domain:  free  text 

9  8  Contact  Instructions  -  text  instructions  to  end  user  on  how  or  when  to  make  contact 

with  an  individual  contact  person 
Type:  text 

Domain:  free  text 
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Contact  Information  Element  Context  Svntax: 


Contactlnformation  = 

[ContactPersonPnmary 

Contact  Organization  Pnmarv]  - 
(ContactPosition)  ♦ 
Contact_Mail_Address  * 

1  {Contact_Voice_Telephone}n  - 
(1  {Contact_Facsimile_Telephone}n)  - 
(1  {Contact_Electronic_Mail_Address}n)  * 
(Contact  Instructions) 

ContactPersonPrimary  = 

(ContactOrganization)  + 

Contact_  Person 


Contact_Organization_Primary  = 


Contact_Organization  + 
(Contact_Person) 
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Appendix  A 


Reading  the  Metadata  Content  Syntax 


Overview 


The  content  syntax  section  describes  the  structure  and  relationships  among  the  data  elements  Each 
production  rule  has  a  left  side  (identifier)  and  right  side  (expression)  connected  by  the  symbol  meaning 
that  the  left  side  is  replaced  by  or  produces  the  right  side.  Making  substitutions  using  matching  symbols  in 
the  production  rules  leads  to  explaining  the  highest  level  identifier  in  terms  of  lower  level  symbols 

The  symbols  used  in  the  production  rules  have  the  following  meaning: 


Svmbol 


+ 

(I] 

m{}n 

0 

Examples: 


b  + 
c 

a  consists  of  b  and  c 


Meaning 

Is  replaced  by,  producers,  consists  of 
And 

Selection  -  select  one  term  from  the  list  of  enclosed  terms  (exclusive 
or).  Terms  are  separated  by 

Iteration  -  the  term(s)  enclosed  is(are)  repeated  from  "m"  to  "n"  times 
Optional  •  the  term(s)  enclosed  is(are)  optional 


a  « 

4{b}6 

a  consists  of  four  to  six  occurrences  of  b 


a  ■ 

[b  I 

c] 


a  consists  of  one  of  b  or  c 


b  + 

(c) 

a  consists  of  b  and  optionally  c 
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Default  Theme  Keyword  Thesaurus' 


Appendix  B 


Thesaurus  Title:  FGDC  Content  Standards  for  Spatial  Metadata  default  thesaurus 
Kev-words: 


ANTHROPOGENIC  • 

Administrative  Units  • 
Cadastral  * 

Census  Units  * 
Communication  Lines  • 
Named  Places  • 
Pipelines  • 


Political  Units  • 
Populated  Places  • 
Population  • 

Public  Land  Survey 
Railroads  * 

Roads  * 


Structures  • 
Transmission  Lines  • 
Transportation  • 
Waterways  • 


ATMOSPHERIC  COMPOSITION 


Aerosols 
Air  Quality 
Ash 

Carbon  Dioxide 
Chloro  fluorocarbons 
Clouds 


Contaminants 
Humidity 
Methane 
Nitric  Acid 
Nitrogen 

Nitrogen  Dioxide 


Oxygen 

Ozone 

Trace  Elements 
Trace  Gases 
Tracers 
Water  Vapor 


ATMOSPHERIC  DYNAMICS 
Altitude 

Atmospheric  Temperature 
Climate  • 

Cloud  Types 

Evaporation 

Evapotranspiration 


Geopotentia]  Height 

Pressure 

Heat  Flux 

Solar  Radiation 

Humidity 

Storms 

Paleoclimate  Indices 

Visibility 

Precipitation 

Winds 

BIOLOGICAL  ENTITIES 
Birds 

Domesticated  Animals 
Domesticated  Plants 
Endangered  Species 


Land  Wildlife 
Microorganisms 
Minor  Species 
Ocean  Vegetation 


Ocean  Wildlife 
Surface  Vegetation 


*  Adap,ed  fro™  Directory  Interchange  Format  (DIF)  Manual.  April  1993  version  4.1.  section  2.11. 
Parameter  measured.”  Entries  marked  with  an  asterisk  (*)  are  extensions  to  the  DIF  Manual. 
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Addiction 

Bacterial 

Cardiovascular 

Chronic 

Communicable 

Dermatologic 

Digestive  System 

Endocrine 

Eye 

Fungal 


Immunologic 

Infection 

Injury 

Musculoskeletal 

Neonatal 

Neoplasms 

Nervous  System 

Nutritional  and  Metabolic 

Occupational 

Ophthalmic 


EARTH  RADIATIVE  PROCESSES 

Irradiance 
Radiance 
Solar  Activity 


Albedo 

Brightness  Temperature 
Heat  Flux 


GEODYNAMIC  FEATURES 

Earthquakes 

Erosion 

Geodesy 

Geothermal 


Gravity  Fields 
Magnetic  Fields 
Polar  Motion 
Seismic 


GEOGRAPHY  AND  LAND  COVER 

Ice 

Lakes 
Landforms 
Rivers 
Snow 


Albedo 

Cultural  Features 
Elevation 
Fires 
Glaciers 


GEOLOGICAL  PARAMETERS 

Age  Determinations 
Aquifer  • 

Coal 

Economic  Minerals 
Geochemical  Analysis 

HEALTH  CARE 
Clinical  Care 


Igneous  and  Metamorphic  Rocks 
Lithology 

Mineralogy  and  Crystallography 

Paleontology 

Petroleum 


Community  Care 


Otorhinolaryngologic 

Parasitic 

Poisoning 

Pregnancy  Complications 

Respiratory 

Skin 

Stomatognatic 

Urologic 

Virus 


Temperature 
Thermal  Inertia 


Structures 
Tectonophysics 
Terrain  Elevation 
Volcanoes 


Soils 

Surface  Vegetation 
Surface  Water 
Topographic  Data 
Wetlands 


Petrology 
Sedimentary  rocks 
Soils 

Stratigraphy 
Surficial  Geology  * 


institutional  Care 
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HYDROLOGIC  PARAMETERS 


Contamination 

Deposition 

Erosion 

Evaporation 

Glaciers 

Ground  Water 

Infiltration 

Oxygen  Demand 

Precipitation 

Rivers 

Runoff 

Sedimentation 

Solids 

Surface  Water 

Temperature 

Turbidity 

Water  Vapor 

Wetlands 

MAGNETIC  AND  ELECTRIC 

FIELDS 

Activity  Indices 

Electric  Fields  (DC) 

Electric  Wave  Spectra  (AC) 
Magnetic  Fields  (DC) 

Magnetic  Wave  Spectra  (AC) 

OCEAN  COMPOSITION 

Alkalinity 

Aquatic  Plants 

Biomass 

Carbon  Dioxide 

Chemical  Tracers 

Chlorophyll 

Conductivity 

Dissolved  Solids 

Light  Transmission 

Major  Elements 

Minor  Species 

Nitrate 

Nitric  Acid 

Nitrite 

Nitrogen 

Nitrogen  Dioxide 

Nutrients 

Ocean  Wildlife 

Organic  Matter 

Oxygen 

pH 

Phosphates 

Phytoplankton 

Pigment  Concentration 
Pollutants 

Salinity 

Sea  Ice 

Sediments 

Silicate 

Suspended  Solids 

Trace  Elements 

Upwelling 

Zooplankton 

OCEAN  DYNAMICS 

Bathymetry 

Brightness  Temperature 

Currents 

Evaporation 

Geopotential  Height 

Heat  Flux 

Pressure 

Primary  Production 

Sea  Ice 

Sea  Level 

Sea  Surface  Height 

Sedimentation 

Swell 

Temperature 

Tides 

Turbidity 

Upwelling 

Waves 

Winds 

PUBLIC  HEALTH 

Accidents 

Behavior 

Disease  Outbreaks 

Drug  Contamination 

Environmental  Health 

Epidemics 

Epidemiologic  Measurements 
Food  Poisoning 

Nutrition 

VITAL  STATISTICS 

Demography 

Morbidity 

Mortality 
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C.  COMPLEX  DATA  TASK  FORCE  MEETING  BRIEFING  CHARTS 
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Use  State-of-practice  User  defined  data  types 
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256_PalletColor  |  TRU_Red 

TRU_Green 
TRU  Blue 
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Heterogeneity  in  DMSO  community 


Interoperability  and  data  exchange 


Data  translation/conversion 
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Target  architecture  based  on  data 
standardization 


Evolutionary  migration  to  target  architecture 
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modification 


Evolutionary  migration  to  target  architecture 
(concluded) 
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Repository  role  in  data  translation/conversion 
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Repository  role  in  data  translation/con  version 
(continue) 


Repository  role  in  data  translation/con  version 
(concluded) 
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be  of  variable  length,  or  any  data  structures 
which  requires  a  pointer. 
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represent  information  ina  variety  of  forms 

Assembly  -  Data  entities  comprising  instances  fo  data  which 

relate  to  other  instances  of  data  within  the  same  entity. 
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Logical  Data  Model  for  Documenting  Composite  Element  Associations 
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Today's  Opportunity: 

Focus  of  current  research  is  on  documenting  complex  data  streams. 
An  opportunity  exists  to  set  standards  to  fulfill  data  sharing  needs. 
(Last  two  bullets) 
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Preliminary  Logical  Data  Model  for  Administering  Complex  Data  Streams  as  Reusable  Assets 
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Geographic  terrain  features  such  as  roads,  rivers  and 
facilities. 


Intelligent  Key:  One-to-many  recursive  relationship  i^rent  Entity - 

based  on  intelligence  embedded  in  the  coded  values  of  Intelligent  Kev 
the  key  (e.g.,  0.0, 1.0, 1.1, 1.1.1, 1.1.2, 1.1.2.1)  - E - 

Non-key  Attributes 


Example  Alternative  Profiles  for  Modeling  Recursion 


work  together  on  meeting  common  goals  and  needs 
about  complex  data  elements. 
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Executive  Summary 

This  paper  analyses  four  types  of  complex  data  that  will  impact  the  data 
administration  program: 

1.  Composite  Elements  -  formulations  that  bundle  or  embed  multiple 
concepts  within  a  single  fixed  format  data  element 

2.  Derived  Elements  -  calculations  or  aggregations  assimilated  from 

primitive  observations.  -  * 

3.  Complex  Data  Streams  -  sequential  arrangements  of  bits  and/or  bytes 
in  varying  lengths  used  to  communicate  information  through,  for  example,  word 
processing,  graphics,  voice,  or  multi-media  applications. 

4.  Assemblies  -  entities  which  have  relationships  to  themselves  (i.e., 
instances  within  the  entity  relate  recursively  to  other  instances  within  the  same 
entity).  Organization  structures,  equipment  assemblies  and  subassemblies,  and 
geographic  terrain  features  such  as  roads,  rivers,  and  facilities  all  represent  examples 
of  assemblies. 

The  analysis  is  performed  to: 

1.  Document  evaluation  criteria  for  deciding  when  composite  data 
elements  and  derived  data  elements  should  be  adopted  and  managed  as  standard  dpfl* 
elements. 

2.  Develop  relational  models  far  documenting  data  element  associations  in 
composite  data  elements  and  derived  data  elements,  »nd  for  supporting  the  reuse  of 
complex  data  streams.  These  models  provide  a  basis  for  updating  data  dictionaries 
designed  to  support  reuse  of  these  various  types  of  complex  data  Specifically,  the 
models  for  composite  and  derived  data  elements  will  provide  a  basis  for  updating  the 
DDRS.  The  model  for  complex  data  streams  identifies  data  elements  which  are 
important  for  standardization  at  a  national  and  international  level  to  improve  the 
interoperability  of  object  oriented  software  packages  being  developed  to  support  the 
reuse  of  complex  data  streams. 

3.  Outline  approaches  for  improving  the  reuse  management  of  entity 
.tj  nj  which  describe  assembly  type  objects. 

Recommendations  developed  for  each  of  the  types  of  complex  daft  discussed  in 
paper  are  summarized  in  Table  1  below.  The  table  lists  die  four  types  of  en*npte» 
data,  specific  recommendations  for  improving  their  management  for  reuse,  a«d  the 
rationale  for  these  recommendations. 
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gHH 

Recommendation  for  Improving  Management  for 
Reuse 

Rationale  for  Recommendation 

Composite 

Elements 

Document  associations  among  data  elements  provide 
the  basis-for  the  composite  .element's  formulation.  A 
data  model  far  documenting  associations  is  provided  m 
Chapter  2. 

Consider  standardizing  a  composite  it  is 
institutionalized  and  does  not  contain  components 
having  independent  uses  outside  the  composite. 

Distinguish  between  logical  and  physical  representations 
of  data  elements.  Implementation  issues  concerning 
performance  and  storage  may  lead  to  situations  where 
composite  formulations  are  more  desirable  than  single 
concept  formulations.  In  these  situations  it  is  best  to 
document  the  difference  between  the  logical  and 
physical,  and  the  rationale  for  the  choice  made. 

Capturing  Association  information 
promotes  understanding  of  the  data, 
improves  its  sharing,  and  supports 
efforts  to  migrate  legacy  elements  to 
single  concept  elements. 

Costs  far  standardizing  an 
institutionalized  chain  can  exceed 
the  benefits.  Because 
institutionalized  elements  appear  in 
numerous  databases,  numerous  * 
configuration  management  tasks 
would  result  from  changing  their 
formulation. 

Derived 

Elements 

Standardize  derivatives  used  in  transaction  systems 
when  support  accounting,  auditing,  policy,  or  business 
rule  enforcement. 

Manage  data  models  for  DSS  functions  separately  from 
data  models  for  transaction  oriented  systems.  Consider 
adopting  derived  elements  supporting  DSS  uses  if  their 
use  is  formalized  in  official  DoD  documents,  used  in 
multiple  functional  areas,  or  shared  with  external 
organizations. 

Map  a  standardized  derived  element  to  its  constituent 
primitive  source  elements. 

These  elements  are  of  'corporate 
interest',  and  cataloging  their 
specifications  as  standards  improves 
corporate  knowledge  about  foe  data, 
and  foe  business. 

Documenting  foe  association 
between  a  derived  element  and  its 
primitive  source  elements  improves 
coordination  and  communication 
about  how  commonly  used 
derivations  are  to  be  calculated. 

Complex 

Data 

Streams 

Design  and  implement  a  standard  architecture  for 
cataloging  and  retrieving  documents,  graphics,  voice, 
video  and  other  complex  data  streams.  This  ear  be 
done  using  relational  database  technologies,  but  object 
oriented  technologies  provide  a  natural  solution 
framework. 

Initiate  a  project  to  standardize  elements  critical 
identifying,  categorizing  and  sharing  complex  data 
streams  at  a  national  or  international  level. 

PH 

Assemblies 

Develop  guidelines  for  modeling  assemblies  using 
standard  templates  and  extensions  that  conunumcate 

Guidelines  will  improve 
corrmnmicatiori  about  foe  assembly. 

concepts  not  represented  by  entity-relationship  models. 

Identify  assembly  type  objects  in  data  models  and 
manage  them  for  reuse  independently  of  the  functional 
models. 

Reuse  management  will  c^ritalire 
on  pest  analysis  and  promote 
improvement  of  foe  assembly 
documentation  over  tune. 

Table  1  Summary  of  Recommendations 


In  formulating  the  recommendations,  goals  for  improving  data  sharing,  data 
quality,  and  data  security  were  promoted.  But  requirements  to  achieve  these  goals  in 
a  cost  effective  and  timely  manner  also  require  the  standardization  efforts  be  focused 
on  data  that  are  shared.  All  data  within  the  department  are  of  corporate  interest,  but 
the  standardization  program  must  be  responsive  to  priorities;  todays  standardization 
efforts  should  focus  on  today's  data  sharing  requirements.  DoD's  data  standardization 
efforts  would  benefit  its  customers  if  it  focused  on  standards  and  agreements  that 


I 
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outline  the  formats  used  to  exchange  data  between  existing  Automated  Information 
Systems. 


To  support  these  recommendations,  daEt  administration  tools  need  to  be 
extended  to  capitalize  on  a  synergism  between  data  modeling  techniques  and  data 
analysis  techniques.  The  data  analysis  techniques  include  domain  comparison, 
synonym  and  homonym  checks,  metadata  audits,  configuration  management  of  data 
exchange  needs,  and  analysis  of  existing  data  exchange  formats.  These  data 
analyses  techniques  can  be  used  to  accelerate  the-discovery  and  definition  of  joint 
functional  requirements.  They  can  also  be  used  to  accelerate  the  standardization  of 
look-up  tables,  reference  tables,  or  domain  tables  (e.g.,  country  code,  pay  plan  code, 
location  code,  etc.);  this  would,  in  effect,  jump  start  the  extension  of  the  DoD  Data 
Model. 
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DATABASE  BROWSE  SYSTEM 
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•  Captures  the  End-Use  Specific  Data  Hierarchy,  and 
-  Associates  Vertices  by  Edges,  not  Identities  by  Attributes 
Employs  Superior  Level  "Data”  as  Subordinate  Level  “Meta-Data”. 
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The  Problem 

•  DAS3  data  nnictures  contain  their  own  linkage  information. 

•  Requires  •  fixed  model  of  relationships  among  data. 

No  provision  for  missing  or  unforeseen  data  structures. 

.  Attempts  to  increase  generality  lead  ao  a  proliferation  of  linkage  fields. 
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DAS4  Dcsiga  Gmk 


*  Store  dn  from  a  SONAR  exercise  of  vbitrwy  complexity. 


•  Express  any  level  of  detail  that  is  appropriate. 

•  Allow  men  to  apply  alternate  models  to  a  common  set  of  dan 
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The  Solution 

•  Any  givcnaei  of  data  and  its  relations  can  be  expressed  as  a  graph. 

•  Removing  the  fields  from  the  data  structures  produces  a  design  with 


*  the  relations  among  the  data  dements  (edges), 

-  the  modd  lo  which  the  relations  conform  (production  rules). 
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Benefits 


•  The  set  of  DAS4  data  structures  may  be  expended  with  no  effect  on  existing 
files. 


•  An  application's  unique  requirements  are  met  by  specifying  an  appropriate 
model  of  the  relationships  among  DAS4  data  elements. 

•  Potting  of  data  between  applications  can  be  automated  by  a  mechanism  that 
transforms  one  model  into  another. 

•  A  single  pool  of  data  may  be  shared  by  any  number  of  applications, 
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•Application/Implementation  Independence 
•Single  Name-  Single  Meaning 
MC&G  Data  Elements  must  be  Standardized 


REASONS  FOR  IDEF  MODELING 
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PILOT  PROJECT  RATIONALE 
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eature  Attribute  Coding  Catalog 


PROJECT  SCHEDULE 
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Phase  II:  (12  Weeks,  Sept  13-  Nov  19) 

•  Develop  Data  Model 

•  Prepare  Standard  Data  Element  package 
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DDRS  SUBMISSION 
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DoD  Team  Concept 
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DoD  Enterprise  Model  Enhancements 
Data  Elements  usable  ‘DoD-wide’ 


ADVANTAGES 


Eliminates  redundancy 

Expedites  Data  Element  Approval  Process 
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Must  have  experienced  players  on  team 

•  Players  must  be  empowered  to  speak  for 
their  organizations! 


The  DMA  fully  attributed,  normalized  model  is  on  pages  4-13  through  4-31.  The  glossary  begins  on 
page  4-33  and  is  followed  by  the  business  rules  on  page  4-50.  A  guide  to  reading  a  data  model  is 
located  in  Appendix  A. 

The  DMA  MC&G  Standardization  Pilot  Project  Data  Model  has  die  following  page  layout: 


ntr> -Code  Org-ID 


Feature-/ 


797 


ulifier-Description-Text 


GS -Topological-Ell 
GS-Topological-El) 


lOS-Line-C! 


Geospatial-Feature- 


(■•1-Feature- Anribute-Rcleue-Restriction 


Ocospatiat-Suffacc-Regron-Bounding-CIosed'Line  Geospatial-Line-Point _ 

foMwhc*-Repoo-lD(FK)  foS-Une-ID(FK) 

OS-Gcaed-Line-ID  (FK)  OS-Point-ID  (FK) 

OS-Sujftce-Regkm-BoujKlmtj-Cloged-Line-Code  OS-Line-Point -Sequence-Identifier 
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Fully  Attributed  Entity  Definitions 

ALTERNATE-GEOSPATIAL-FEATURE-REPRESENTATION 

An  independent  model  of  a  geospatial  feature.  The  data  extraction  process  permits  capturing  different 
representations  of  the  same  real  world  object.  These  representations  are  related  to  each  other  through 
this  entity. 

COMPONENT-GEOSPATIAL-FEATURE-REPRESENTATION 


A  geospatial  feature  representation  that  comprises  an  element  of  a  complex  geospatial  feature 
representation. 


COUNTRY 

A  sovereign  state.  Typically  an  autonomous  political  unit;  also  called  a  nation. 

This  entity  is  only  a  shadow  entity  in  die  DMA  Data  Model.  DMA  believes  it  is  not  responsible  for 
defining  and  modeling  die  entity  Country. 

COUNTRY-GEOSPAHAL-FEATURE-ATTRIBUTE-RELEASE-RESTRICnON 

A  constraint  controlling  die  release  of  specific  data  about  a  geospatial  feature.  The  constraint  may 
prohibit  or  permit  said  release  to  a  country,  as  indicated  by  die  country  releasibility  attribute. 

COUNTRY-GEOSPATIAL-FEATURE-ATntIBUTE-USE-CONSTRAINT 

The  limitations  to  the  use  a  receiving  country  may  make  of  specific  information  about  a  geospatial 
feature. 


COUNTRY-GEOSPAlIALrFEATURE-REPRESENTATION-RELEASE-RESTRICTION 

A  constraint  controlling  die  release  of  a  geospatial  feature  representation.  The  constraint  may  prohibit 
or  permit  said  release  to  a  country,  as  indicated  by  die  country  releasibility  attribute. 

COUNTRY-GEOSPATTAL-FEATURE-REPRESENTATION-USErCONSTRAINT 


The  limitation  to  the  use  a  receiving  country  may  make  of  a  geospatial  feature  representation. 


GEOSPATIAL- 


wrier.*  i 


-LINE 


A  non-self-intersecting  geospatial  line  specified  by  at  least  four  geospatial  points  in  which  die 
geospatial  line  starting  point  and  die  geospatial  line  ending  point  are  die  same. 
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GEOSPATIAL-EDGE 

A  one-dimensional  topological  element  bounded  by  one  geospatial  starting  node  and  one  geospatial 
ending  node  and  located  by  a  geospatial  line.  A  geosopatial  edge  is  directed  from  start  node  to  end 
node.  When  an  edge  is  a  part  of  a  more  complex  structure,  its  directionality  may  be  used  as  die  basis 
for  ideas  such  as  "right”  and  "left". 

GEOSPATIAL-EDGE-ENDING-NODE 

A  geospatial  node  identified  as  the  ending  node  of  a  geospatial  edge. 

GEOSPATIALrEDGE-STARTING-NODE 

A  geospatial  node  identified  as  the  starting  node  of  a  geospatial  edge. 

GEOSPATIAL-EDGE-TERMINAL-NODE 

A  geospatial  node  which  is  either  the  starting  or  ending  node  for  a  specific  geospatial  edge. 
GEOSPATIAL-EXTERN AL-BOUNDING-CLOSED-LINE 

The  geospatial  surface  region  bounding  closed  line  which  defines  die  exterior  boundary  of  a  geospatial 
surface  region. 

GEOSPATIAL-EXTERNAL-FACE-RING 

The  geospatial  face  ring  which  defines  die  exterior  boundary  of  a  geospatial  face. 
GEOSPATIAL-FACE 

A  topological  region  enclosed  by  a  geospatial  ring.  A  geospatial  facehas  its  locus  defined  by  a 
geospatial  surface  region. 

GEOSPATIAL-FACE-RING 

The  geospatial  ring  which  is  a  boundary  of  a  geospatial  face.  The  ring  may  be  an  internal  boundary. 
The  ring  may  be  die  external  boundary. 

GEOSPATIAL-FEATURE 

An  identifiable  object  relative  to  the  Earth’s  surface.  A  wide  variety  of  identifiable  objects  exist  on 
and  sometimes  above  or  below  die  Earth’s  surface.  Included  among  these  are  moveable  or  temporal 
objects  (trucks,  command  posts,  etc.),  and  temporary  structures  (tents,  shelters,  etc.).  While  these 
are  of  interest  or  concern  from  many  perspectives,  the  geospatial  perspective  considers  only  those 
features,  natural  and  man-made,  that  remain  stationary  or  recur  in  the  same  place  over  a  significant 
length  of  time. 
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GEOSPATIAL-FEATIJRE'ATTRIBUTE 
A  characteristic  of  a  geospatial  feature. 

GEOSPATIAL-FEATURE-ATTRIBUTE-CLASS 

The  generic  description  of  a  specific  geospatial  feature  attribute.  DIGEST  provides  a  list  of  attribute 
classes,  codes  and  descriptors  in  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  on  Page  4-6 
in  Section  4  for  a  fuller  understanding  of  how  the  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-CLASS-QUALIFIER 

Information  that  provides  further  detail  within  a  geospatial  feature  attribute  class  that  may  be  used  for 
geospatial  feature  characterization.  DIGEST  provides  the  lists  of  available  qualifier  (value)  codes  and 
descriptors  in  Part  4  Annex  B.  Refer  to  foe  instance  tables  provided  on  Page  4-6  in  Section  4  for  a 
fuller  understanding  of  how  foe  model  employs  these  concepts. 

GEOSPATIAI^FEATURE-ATTRIBUTE-DESCRIPTOR 

The  variable  length  text  string  providing  descriptive  detail  to  a  geospatial  feature  attribute  as  required 
by  foe  attribute  class.  For  example,  foe  feature  attribute  class  'Name'  requires  that  foe  mm*  of  foe 
feature  be  provided  as  a  text  string.  Refer  to  foe  instance  tables  provided  on  Page  4-7  in  Section  4 
for  a  fuller  understanding  of  how  foe  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-DETAIL 

/ 

Information  about  a  specific  geospatial  feature  that  provides  a  more  detailed  description  of  a 
geospatial  feature  attribute.  The  detail  is  one  of  three  types,  which  are  geospatial  feature  attribute 
descriptor,  geospatial  feature  attribute  measurement,  and  geospatial  feature  attribute  qualifier. 

DIGEST  Part  4  Annex  B  provides  a  list  of  standard  values  for  each  attribute.  Refer  to  foe 

tables  provided  on  Page  4-7  in  Section  4  for  a  fuller  understanding  of  how  foe  model  employs  these 

concepts. 


GEOSPATIAL-FEATURE-ATTRIBUTE-DETAIL-SOURCE 

Information  about  a  specific  source  for  determining  a  geospatial  feature  attribute  detail. 

GE05PATTAL-FEATURE-ATTRIBUTE-MEASUREMENT 

The  measured  value  of  a  specific  geospatial  feature  attribute.  Refer  to  the  instance  tables  provided  oo 
Page  4-7  in  Section  4  for  a  fuller  understanding  of  how  foe  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATrRIBUT&QUALIFIER 

The  specific  geospatial  feature  attribute  class  qualifier  used  to  provide  foe  detail  description  of  a 
specific  geospatial  feature  attribute.  Refer  to  foe  Instance  tables  provided  on  Page  4-7  in  Section  4  for 
a  fuller  understanding  of  how  foe  model  employs  these  concepts. 
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GEOSPATIAL-FEATURE-ATTRIBUTE-SECURrrY-CLASSIFICATlON 
A  security  classification  assigned  to  data  about  a  geospatial  feature  attribute. 
GEOSPATIAI^FEATURE-REPRESENTATION 

A  model  of  a  geospatial  feature.  The  model  provides  geometric  and  descriptive  characteristics  of  die 
feature.  The  geometric  portion  of  die  model  portrays  the  feature's  size,  shape,  position  and 
connectivity  using  geometric  and  topologic  elements.  The  descriptive  portion  of  die  model  contains 
attribute  detail  descriptions,  attribute  qualifiers,  and  attribute  measurements. 

GEOSPAHALtFEATURE-REPRESENTATION-GEOMETRY 

The  association  between  a  geospatial  feature  representation  and  its  geospatial  geometric  element. 

GEOSPATIAL-FEATURE-REPRESENTATION-IDENTIFICATION-ACCURACY 

The  probability  that  die  geospatial  feature  code  has  been  correctly  assigned  to  a  geospatial  feature 
representation. 

GEOSPATIAL-FEATURE-REPRESENTATION-SECURITY-CLASSIFICATION 

The  classification  assigned  to  a  geospatial  feature  representation. 

GEOSPATIAL-FEATURE-REPRESENTATION-SOURCE 

The  geospatial  source  from  which  information  about  a  geospatial  feature  was  extracted. 

GEOSPATIAL-FEATURE-REPRESENTATION-VALIDATION 

The  finding  that  a  geospatial  feature  representation  is  complete. 

GEOSPATIAL-FEATURE-REPRESENTATION-VERTICAL-ACCURACY 

Information  about  the  errors  associated  with  the  determination  of  die  elevation  of  geospatial  points 
used  in  die  geospatial  feature  representation  geometry. 

GEOSPATIAL-GEOMETRIC-ELEMENT 

A  component  of  a  geospatial  feature  representation  which  provides  information  about  size,  shape,  and 
position.  A  geometric  element  may  have  a  topologic  element  associated  with  it. 

GEOSPATIAL-INTERNAL-BOUNDING-CLOSED-UNE 

A  geospatial  surface  region  bounding  closed  line  used  as  an  interior  boundary  of  a  geospatial  surface 
region. 
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GEOSPATIAL-INTERNAL-FACE-RING 

A  geospatial  face  ring  used  as  an  interior  boundary  of  a  geospatial  face. 

GEOSPATIAL-LINE 

One  of  three  types  of  geometric  element,  defined  by  a  set  of  geospatial  points  in  an  ordered  sequence. 
The  defining  points  are  connected  by  straight  line  segments. 

GEOSPATIAL-LINE-ENDING-POINT 

A  geospatial  line  terminal  point  identified  as  the  last  point  in  a  sequence  of  points  that  defines  a 
geospatial  line. 

GEOSPATIAL-LINE-POINT 

A  geospatial  point  that  is  part  of  a  set  used  in  defining  a  geospatial  line. 
GEOSPATIAL-LINE-STARTING-POINT 

A  geospatial  line  terminal  point  identified  as  die  first  point  in  a  sequence  of  points  that  defines  a 
geospatial  line. 

GEOSPATIAL-UNE-TERMINAL-POINT 

'  / 

There  are  exactly  two  geospatial  points  designated  terminal  points  for  each  line.  One  geospatial  point 
is  a  terminal  end  point  and  one  is  a  terminal  start  point. 

GEOSPATIAL-NODE 

A  zero  dimensional  topological  primitive  used  to  define  topologic  relationships.  A  geospatial  node  Is 
always  associated  with  a  geospatial  point. 

GEOSPATIAL-PATH 

A  set  of  edges  connected  at  their  terminal  nodes,  such  that  no  node  is  shared  by  mote  than  two  edges 
of  the  set 

GEOSPATIAL-PATH-EDGE 

A  geospatial  edge  used  as  a  component  of  a  geospatial  path. 
GEOSPATIALPATH-EDGE-SEQUENCE 

Information  about  the  order  of  the  assembly  of  a  geospatial  path.  This  entity  associates  a  geospatial 
edge  used  as  a  geospatial  path  edge  to  the  succeeding  geospatial  edge  in  the  path. 
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GEOSPATIAL-POINT 

The  zero  dimensional  primitive  that  assigns  the  geodetic  position.  Latitude,  longitude,  and  elevation, 
if  available,  are  defined  in  WGS  84.  (See  DMA  Technical  Report  8350.2.) 

GEOSPATIAL-POINT-ELEVATION 

A  geospatial  point  elevation  assigns  an  elevation  to  a  geospatial  point.  The  elevation  is  referenced  to 
mean  sea  level. 


GEOSPATIAL-POSITION-EL 


NT 


An  element  of  geometry  or  topology  used  for  real  or  conceptual  delineations  relative  to  the  surface  of 
die  earth.  Geometric  elements  include  geospatial  point,  geospatial  line,  and  geospatial  surface  region. 
Topologic  elements  include  geospatial  node,  geospatial  edge,  geospatial  face,  geospatial  shell,  and 
geospatial  path. 

GEOSPATIAL-RING 


A  closed  geospatial  path.  In  a  closed  geospatial  path,  every  geospatial  terminal  node  in  the  path  is 
shared  by  two  of  die  edges  that  make  up  die  path.  A  geospatial  ring  bounds  a  geospatial  face. 

GEOSPATIAL-SHELL 


An  open  connected  set  of  two  or  more  geospatial  faces. 

GEOSPATIAL-SHELL-FACE 

Information  that  a  specific  geospatial  face  is  a  member  of  a  set  that  composes  a  geospatial  shell. 
GEOSPATIAL-SOURCE 


Data  of  any  type  from  which  geospatial  feature  information  can  be  extracted.  Sources  include,  but 
are  not  limited  to,  ground  control,  aerial  and  terrestrial  photographs,  sketches,  maps,  and  charts; 
topographic,  hydrographic,  hypsographic,  magnetic,  geodetic,  oceanographic,  and  meteorological 
information;  intelligence  documents  and  written  reports  pertaining  to  natural  and  man-made  features 
of  the  area  to  be  mapped  or  charted. 

This  entity  is  only  a  shadow  entity  in  die  DMA  Data  Model.  DMA  believes  that  it  does  not  foil 
within  die  scope  of  this  project  to  define  and  model  die  entity  Geospatial-Source. 

GEOSPATIAL-SURFACE-REGION 


A  bounded  segment  of  a  specified  surface.  A  geospatial  surface  region  may  be  bounded  by  a 
geospatial  surface  region  dosed  line.  When  a  geospatial  surface  region  is  die  location  of  a  geospatial 
face,  die  loci  of  the  geospatial  edges  which  make  up  the  geospatial  face  ring  are  die  geospatial  lines 
which  bound  die  geospatial  surface  region. 
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GEOSPATIAL^URFACE-REGION-BOUNDING-CLOSED-LINE 
A  geospatial  surface  region  closed  line  that  bounds  a  geospatial  surface  region. 
GEOSPATIAL-TOPOLOGICAL-ELEMENT 

A  primitive  that  defines  connectivity  and  relationship  of  the  parts  of  the  geospatial  position  dements. 
Every  topological  dement  has  an  appropriate  association  to  a  geometric  dement. 

OPEN-GEOSPATIAL-PATH 

A  geospatial  path  in  which  all  but  two  of  the  geospatial  nodes  are  shared  by  two  geospatial  edges. 
ORGANIZATION 

An  administrative  structure  constituted  to  accomplish  a  goal,  purpose  or  mission.  (Reference 
Working  Draft  of  DoD  Enterprise  Modd;  February  1993.) 

This  entity  is  only  a  shadow  entity  in  die  DMA  Data  Modd.  DMA  bdieves  it  is  not  responsible  for 
defining  and  modeling  the  entity  Organization. 

ORGANIZATION-COUNTRY 

The  primary  association  between  an  organization  and  a  country.  The  association  is  used  to  determine 
disclosures  of  information,  limited  by  country. 

ORGANIZATION-GEOSPATTAL-FEATURE-ATTRIBUTE-RELEASE-RESTRICTTON 

A  constraint  controlling  die  rdease  of  specific  geospatial  feature  attribute  data.  The  constraint  may 
prohibit  or  permit  said  rdease  to  an  organization,  as  indicated  by  the  country  rdeasibility  attribute. 

ORGANIZATION-GEOSPATIAL-I^TURE-ATTRIBUra-USE-CONSTRAINT 

The  limitations  to  die  use  a  receiving  organization  may  make  of  specific  information  about  a 
geospatial  feature  attribute. 

ORGANlZATTON-GEOSPATIAL-FEATURE-REPRESENTATION-RELEASE-RECTRICnON 

A  constraint  controlling  the  rdease  of  a  geospatial  feature  representation.  The  constraint  may  prohibit 
or  permit  said  rdease  to  an  organization,  as  indicated  by  die  organization  rdeasibility  attribute. 

ORGANIZATTON-GEOSPATTALrFEATURE-REPRESENTATTON-USE-CONSTRAINT 

The  limitations  to  the  use  a  receiving  organization  may  make  of  a  geospatial  feature  representation. 

SECURITY-CLASSIFICATION 

Information  established  by  an  authoritative  body  about  a  levd  of  control  of  information  disclosure. 
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Kev  Attribute  Definitions 

Alternate-Geospatial-Fe&ture-Representati  on-Identifier 

The  identifier  that  denotes  an  alternate  geospatial  feature  representation. 

Component-Geospatial-Feature-Representation-Identi  f er 

The  identifier  that  denotes  a  geospatial  feature  that  is  a  component  of  another  geospatial  feature 
representation. 

Composite-Geospatial-Feature-Represen  tation-Identifier 

The  identifier  Oat  denotes  a  geospatial  feature  representation  that  contains  other  geospatial  feature 
representations  as  components. 

Country-Code 

The  code  that  denotes  a  country  as  specified  by  FIPS  PUB  10-3. 

Country-Geospatial-Feature-Attribute-Release-Restriction-Date 

The  date  on  which  a  country  geospatial  feature  attribute  release  restriction  was  established. 

Country-Geospatial-Feature-RepresentatJ  on-Release-Restriction-Date 

The  date  on  which  a  country  geospatial  feature  release  restriction  was  established. 

Geospatial-Closed-Line-Identlfier 

The  geospatial  line  identifier  that  denotes  a  geospatial  closed  line. 

Geospatial-Edge-Identifier 

The  geospatial  topological  dement  identifier  that  denotes  a  geospatial  edge. 
Geospatial-Edge-Tenninal-Node-Type-Code 

The  code  that  denote  a  geospatial  edge  terminal  node  type.  The  type  may  be  a  geospatial  edge 
starting  node.  The  type  may  be  a  geospatial  edge  ending  node. 

Geospatial-Face-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  face. 
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Geo6patiai-Feature-Attribute-Class-Code 

The  code  that  denotes  a  geospatial  feature  attribute  class.  DIGEST  Part  4  Annex  B  provides  a  list  of 
standard  feature  attribute  codes. 

Geospatial-Feature-Attribute-Class-Qualifier-Code 

The  code  that  denotes  a  qualifier  of  the  selected  geospatial  feature  attribute  class.  DIGEST  Part  4 
Annex  B  provides  lists  of  standard  feature  attribute  qualifier  codes.  Refer  to  the  instance  tables 
provided  elsewhere  in  Section  4  for  a  fuller  understanding  of  how  die  model  employs  these  concepts. 

Geospatial-Feature- Attribute*DetaJ  Hdenti  fier 

The  identifier  that  denotes  the  role  name  for  geospatial  feature  attribute  class  code,  geospatial  feature 
representation  producer  organization  identifier,  and  geospatial  feature  representation  identifier. 

Geospatial-Feature-Attribute-Detai  l-Sequence-Identl  tier 

The  sequence  identifier  that  distinguishes  between  several  geospatial  feature  attribute  descriptor  texts 
that  exist  for  die  same  geospatial  feature  attribute  detail  type  code. 

Geospatial-Feature-Attribute-Detail-Type-Code 

A  code  that  denotes  a  type  of  geospatial  feature  attribute  detail.  The  code  denotes  one  of  three  types 
of  geospatial  feature  attribute  detail,  which  are  geospatial  feature  attribute  descriptor,  geospatial 
feature  attribute  measurement,  and  geospatial  feature  attribute  qualifier. 

Geoepntial-Feature-Attribiite-Security-Classifiation-Efl'cctiTe-Date 

The  date  on  which  die  geospatial  feature  attribute  security  classification  was  established. 

Geospatial-Feature-Code 

The  code  that  denotes  a  specific  geospatial  feature  type.  Standard  codes  are  listed  in  DIGEST  Part  4 
Annex  A. 

Geospatial-Feature-Representation-Identifier 

The  identifier  that  uniquely  represents  a  geospatial  feature  representation  produced  by  a  specific 
geospatial  feature  representation  producer  organization. 

Geospatial-reaturc-ReprescPtation-Idcnii  notion- Accuracy-Effective-Date 

The  date  on  which  the  geospatial  feature  representation  identification  accuracy  was  assigned. 

Geospatial-Feature-Representatloo-Producer-Organization-Identifier 

The  identifier  that  denotes  an  organization  as  die  producer  of  a  geospatial  feature  representation. 
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Geospatial-Feature-RepresenUtion-Security-Classification-E/Tective-Date 

The  date  on  which  the  geospatial  feature  representation  security  classification  was  established. 

Geospatial-Feature-Representation-Validation-Date 

The  date  on  which  a  geospatial  feature  representation  validation  is  effective. 

Geospatial-Geometric-Element-Identifier 

The  geospatial  position  element  identifier  that  denotes  a  geospatial  geometric  element.  It  is  die  role 
name  for  geospatial  position  element  producer  organization  identifier  and  geospatial  position  element 
identifier. 

Geospatial-Line-Identifier 

The  geospatial  geometric  element  identifier  that  denotes  a  geospatial  line. 
Geospatial-Line-Point-Sequence-Identifier 

The  identifier  that  denotes  the  position  of  a  specific  geospatial  line  point,  ordering  die  set  of 
geospatial  line  points  that  make  up  a  geospatial  line. 

Geospatial-Line-Terminal-Point-Type-Code 

/ 

✓ 

The  code  that  denotes  a  geospatial  line  terminal  point  type.  The  types  are  geospatial  line  starting 
point  and  geospatial  line  ending  point. 

Geospa  tial-Node-Identifler 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  node. 

Geospatial-Patb-Identi  fier 

The  geospatial  topological  dement  identifier  that  represents  a  geospatial  path. 
Geospatial-Point-Identifier 

The  geospatial  geometric  dement  identifier  that  denotes  a  geospatial  point. 
Geospatial-Posltion-Elenient-Identifier 

The  identifier  that  denotes  a  specific  geospatial  position  dement.  The  producer  organization  assigns  a 
unique  identifier  to  each  instance  of  geospatial  position  dement. 

Geospatial-PodtioD-Eleinent-Producer-Organizatioo-Identiner 

The  organization  identifier  that  represents  a  geospatial  position  dement  producer  organization.  The 
organization  identifier  is  used  as  part  of  the  identification  of  a  geospatial  position  dement. 
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Geospatial-Preceding-Path-Edge-Identifier 

The  identifier  dial  denotes  a  geospatial  edge  that  immediately  precedes  another  edge  in  the  sequence 
of  edges  that  make  up  a  path. 

Geospatial-Ring-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  ring. 

Geospatial-Shdl-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  shell. 
Geospatial-Source-Identificr 

The  identifier  that  denotes  data  of  any  type  from  which  geospatial  feature  information  can  be 
extracted.  The  identifier  will  be  more  clearly  defined  when  Source  is  modeled  more  completely. 

Geospatial-Surface-Region-Bounding-Closcd-Iine-Codc 

The  code  that  denotes  die  type  of  geospatial  surface  region  bounding  closed  line.  There  are  two 
types:  geospatial  external  bounding  closed  line  and  geospatial  internal  bounding  closed  line. 

Geospatial-Surface-Region-Identifier 

/ 

The  geospatial  geometric  element  identifier  that  denotes  a  geospatial  surface  region. 
Geospatial-Topological-Elenient-Identiner 

The  geospatial  position  dement  identifier  that  denotes  a  geospatial  topological  dement.  It  is  die  role 
name  for  geospatial  position  demem  producer  organization  identifier  and  geospatial  position  dement 
identifier. 

Opcn-Geospatial-Patb-Identifier 

The  geospatial  topological  demem  identifier  that  denotes  an  open  geospatial  path. 

Organization-Identifier 

The  identifier  that  denotes  an  organization. 

Organization-Geospatial-Feature- Attribute-Release-Restriction-Date 

The  date  on  which  an  organization  geospatial  feature  attribute  rdease  restriction  was  established. 

Organization-Geospa  tial-Feature-Representation-Rdease-Restriction-Date 

The  date  on  which  an  organization  geospatial  feature  representation  rdease  restriction  was  established. 


Security-Classification-Code 

The  code  that  denotes  a  level  of  a  classification. 
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Non-Kev  Attribute  Definitions 

Country-Geos  patial-Feature-Attribute-Releasibility-Codc 

The  code  that  denotes  whether  a  country  can  receive  information  about  a  geospatial  feature  attribute. 
If  foe  value  is  yes,  the  geospatial  feature  attribute  may  be  given  to  persons  or  organizations 
representing  that  country,  but  it  may  be  subject  to  constraints  expressed  by  die  organization  geospatial 
feature  attribute  release  restriction  and  country  geospatial  feature  attribute  use  constraint  If  the  value 
is  no,  die  geospatial  feature  attribute  may  not  be  given  to  any  person  or  organization  representing  die 
country. 

Country  GeospatUl-Feature-Attribute-Use-Constraint-Statement-Text 

The  text  identifying  die  limits  to  die  uses  a  receiving  country  may  make  concealing  die  geospatial 
feature  attribute. 

Country*Geospatial-Feature-Representation-Releasibnity-Code 

The  code  that  denotes  whether  a  country  can  receive  a  geospatial  feature  representation. 

If  die  value  is  yes,  die  geospatial  feature  representation  may  be  given  to  persons  or  organizations 
representing  that  country,  but  it  may  be  subject  to  constraints  expressed  by  die  organization  geospatial 
feature  representation  release  restriction  and  country  geospatial  feature  representation  use  constraint 
If  the  value  is  no,  die  geospatial  feature  representation  may  not  be  given  to  any  person  or 
organization  representing  the  country. 

/ 

Country  Geospatial-Feature-Representation-Use-Constraint-Statement-Tcxt 

The  text  identifying  die  limits  to  die  uses  a  receiving  country  may  make  concerning  die  geospatial 
feature  representation. 

Geospatial-Edge4)irection-Code 

The  code  that  denotes  the  direction  in  which  an  edge  is  traversed  when  that  edge  is  a  component  of  a 
geospatial  path.  Normal  traversal  of  a  geospatial  edge  is  from  geospatial  edge  starting  node  to 
geospatial  edge  ending  node.  When  an  edge  is  part  of  a  path,  it  may  be  traversed  in  die  opposite 
direction. 

Geospatial-Face-Ring-Code 

The  code  that  denotes  the  type  of  a  geospatial  face  ring.  There  are  two  types:  geospatial  external 
face  ring  and  geospatial  internal  face  ring. 

Geospatial-Feature- Attribute-Class-Description-Text 

The  text  that  describes  die  geospatial  feature  attribute  class.  These  descriptions  are  provided  in 
DIGEST  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  die  model  employs  these  concepts. 
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Geospatial-Feature-Attribute-Class-Name 

The  name  of  a  geospatial  feature  attribute  class.  A  list  of  these  names  is  provided  in  DIGEST  Part  4 
Annex  B.  Refer  to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller  understanding  of 
how  the  model  employs  these  concepts. 

Geospatial-Feature-Attribute-CIass-Qualifier-Descriptiou-Text 

The  text  that  describes  a  geospatial  feature  attribute  class  qualifier.  These  descriptions  are  provided 
in  DIGEST  Part  4  Annex  B.  Refer  to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  the  model  employs  these  concepts. 

Geospatial-Feature-Attribute-Descri  ptor-Text 

The  text  of  the  geospatial  feature  attribute  descriptor  as  required  by  DIGEST  Part  4  Annex  B.  Refer 
to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller  understanding  of  how  the  model 
employs  these  concepts. 

Geospatial-Feature-Attribute-Detail-Measured-Quantity 

The  quantity  of  the  measured  value  for  the  geospatial  feature  attribute  detail.  The  required  units  of 
measure  are  stated  in  DIGEST  Part  4  Annex  B.  Refer  to  foe  instance  tables  provided  elsewhere  in 
Section  4  for  a  fuller  understanding  of  how  foe  model  employs  these  concepts. 

Geospatial-Feature-Attribute-Detail-Unit-Of-Measure-Text 

The  text  describing  foe  value  of  a  geospatial  feature  attribute  detail.  These  descriptions  are  provided 
in  DIGEST  Part  4  Annex  B.  Refer  to  foe  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  foe  model  employs  these  concepts. 

Geos  pa  tial-Feature-Code-Definiti on-Text 

The  text  describing  foe  distinguishing  characteristics  of  a  geospatial  feature. 
Geospatial-Feature-Represen  tatioo-Extraction-Date 

The  date  on  which  a  geospatial  feature  representation  was  produced  by  a  compilation  from  source 
data. 


8lg 


Geospatial-Feature-Representation-Horizontal-Accuracy-Quantity 

The  quantity  providing  circular  error  bounds  at  the  90%  confidence  level  for  die  geospatial  point 
horizontal  position. 

When  the  horizontal  position  of  an  identified  object  is  stated  in  latitude-longitude  measurements  (phi- 
lambda),  this  places  the  object  horizontally  with  respect  to  die  Earth’s  surface  in  an  Earth-centered 
fixed  coordinate  system.  The  error  associated  with  this  process  expresses  the  uncertainty  with  which 
die  phi-lambda  values  provided  are  correct 

jjMA  states  this  error  as  a  circular  error  (a  phi  =  a  lambda)  at  die  90%  confidence  level  indicating 
that  90%  of  die  placement  measurements  in  a  set  of  measurements  with  the  same  circular  error  will 
be  correct  to  within  die  radius  of  die  error  circle. 

Geospatial-Feature-Representation-IdmtificatiOD- Accuracy-Percent-Quantity 

The  quantity  expressing  die  probability  that  die  geospatial  feature  code  has  been  correctly  assigned  to 
a  geospatial  feature  representation;  the  probability  is  expressed  as  a  percentage. 

Geospatial-Feature-Representation-Validating-Organization-Identirier 

The  identifier  that  denotes  die  organization  that  validated  a  geospatial  feature  representation. 

Geospatial-Feature-Representation-Vertical- Accuracy-Quantity 

The  quantity  providing  linear  error  bounds  at  die  90%  confidence  level  for  geospatial  point 
elevations. 

When  DMA  provides  a  vertical  measurement  positioning  an  object  with  respect  to  its  height,  above  or 
below  mean  sea  level,  the  measurement  is  accompanied  by  an  error  bound,  ±  a  h. 

The  interpretation  of  a  h  is:  In  a  set  of  vertical  measurements,  DMA  is  confident  that  90%  of  the 
stated  values  will  be  within  ±  a  h  of  die  true  value. 

Geospatial-Geoinetric-Elenient'Type-Code 

The  code  that  denotes  a  geospatial  geometric  dement  type.  There  are  three  types:  point,  surface 
region,  and  line. 

Geospadal-IJiie-Closure-Code 

The  code  that  denotes  that  a  geospatial  line  is  a  geospatial  dosed  line. 

Geoepadai-Path-type-Code 

The  code  that  denotes  the  type  of  a  geospatial  path.  There  are  two  types:  geospatial  ring  and  open 
geospatial  path. 
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Geospatial-Point-Elevation-Dimension 

The  elevation  of  a  geospatial  point  in  meters  above  or  below  mean  sea  level. 
Geospatial-Point-Latitude-Coordinate 

One  of  the  coordinates  that  identifies  the  location  of  a  geospatial  point  The  latitude  is  die  angle 
between  die  plane  of  the  geodetic  equator  and  die  normal  to  die  ellipsoid  at  a  point  (measured  positive 
north  from  the  geodetic  equator,  negative  south).  [DMA  Technical  Report  8350.2  -  WGS  84] 

Geospatial-Point-Longitude-Coordinate 

One  of  die  coordinates  that  identifies  die  location  of  a  geospatial  point  The  longitude  is  die  angle 
between  die  plane  of  die  Zero  Meridian  and  die  plane  of  die  geodetic  meridian  of  die  point  (measured 
in  die  plane  of  die  geodetic  equator,  positive  from  0°  to  180°  E,  and  negative  from  0°  to  180°  W). 
[DMA  Technical  Report  8350.2  -  WGS  84] 

Geospa  tial-Position-Element-Extracti  on-Date 

The  date  on  which  a  geospatial  position  element  was  produced  by  a  compilation  from  source  data. 
Geospa  tiatPosition-Element-Type-Code 

The  code  that  denotes  a  type  of  geospatial  position  dement  The  type  may  be  a  geospatial  topological 
dement.  The  type  may  be  a  geospatial  geometric  dement 

Geospa  tial-Succeeding-Path-Edge-Identifier 

The  geospatial  edge  identifier  that  denotes  a  geospatial  edge  that  immediatdy  succeeds  another 
geospatial  edge  in  die  sequence  of  geospatial  edges  diet  make  up  a  geospatial  path. 

Geospatial-Topological-Element-Type-Code 

The  code  that  denotes  a  geospatial  topological  dement  type.  The  five  types  are:  shell,  face,  path, 
edge,  and  node. 

Organization-GeogpatiatFmture-Attributfr-ReleasibiDty-Code 

The  code  that  denotes  whether  an  organization  can  receive  information  about  a  geospatial  feature 
attribute.  If  die  value  is  yes,  the  geospatial  feature  attribute  may  be  given  to  organizations  or 
persons  representing  those  organizations,  but  it  may  be  subject  to  constraints  expressed  by  the 
organization  geospatial  feature  attribute  release  restriction  and  country  geospatial  feature  attribute  use 
constraint.  If  die  value  is  no,  the  geospatial  feature  attribute  may  not  be  given  to  any  organizations  or 
persons  representing  those  organizations. 
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Organization-Geos  patia  1-Feature-Attribute-Use-Cons  traint-Statement-Text 

A  text  that  describes  the  limits  to  die  uses  a  receiving  organization  may  make  concerning  die 
geospatial  feature  attribute. 

Organization-Geos  pa  tial-Feature-Representation-Releasibility-C  ode 

The  code  that  denotes  whether  an  organization  can  receive  a  geospatial  feature  representation.  If  die 
value  is  yes,  the  geospatial  feature  may  be  given  to  organizations  or  persons  representing  those 
organizations,  but  it  may  be  subject  to  constraints  expressed  by  the  organization  geospatial  feature 
representation  release  restriction  and  country  geospatial  feature  representation  use  constraint.  If  the 
value  is  no,  the  geospatial  feature  representation  may  not  be  given  to  any  organizations  or  persons 
representing  those  organizations. 

Organization-Geospatial-Feature-Representation-Use  Constraint-Statement-Text 

The  text  that  describes  the  limits  to  the  uses  a  receiving  organization  may  make  concerning  die 
geospatial  feature  representation. 
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Busintts.Buitt 

Every  Alternate-Geospatial-Feature-Representation 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial-Feature-Representation. 

Every  Component-Geospatial-Feature-Representation 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial-Feature-Representation. 

Every  Country 

always  is  assigned  zero,  one  or  many  Country -Geospatial-Feature-Attribute-Release-Restriction(s). 
always  is  assigned  zero,  one  or  many  Country-Geospatial-Feature-Representation-Release- 
Restriction(s). 

always  is  part  of  zero,  one  or  many  Organization-Country(s). 

Every  Country-Geospatial-Feature-Attribute-Release-Restriction 
may  be  a  Country-Geospatial-Feature-Attribute-Use-Constraint, 

depending  on  Country-Geospatial-Feature-Attribute-Releasibility-Code. 
always  has  a  Country, 
always  has  a  Geospatial-Feature-Attribute. 

Every  Country-Geospatial -F  eature-Attribute-U se-Constraint 
is  a  Country-Geospatial-Feature-Attribute-Release-Restriction. 

Every  Country-Geospatial-Feature-Representation-Release-Restriction 
may  be  a  Country -Geospatial-Feature-Representation-Use-Constraint, 

depending  on  Country-Geospatial-Feature-Representation-Releasibility-Code. 
always  has  a  Country. 

always  has  a  Geospatial-Feature-Representation. 

Every  Country-Geospatial-Feature-Representation-Use-Constraint 
is  a  Country-Geospatial-Feature-Representation-Release-Restriction. 

Every  Geospatial-Closed-Line 
is  a  Geospatial-Line. 

always  is  used  as  zero,  one  or  many  Geospatial -Surface-R^ioD-Bounding-Closed-Line(s). 

Every  Geospatial-Edge 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial-Line, 
always  is  assigned  2  Geospatial-Edge-Terminal-Node(s). 
always  is  used  as  zero,  one  or  many  Geospatial -Path-Edge(s) . 

Every  Geospatial-Edge-Ending-Node 
is  a  Geospatial-Edge-Terminal-Node, 
always  has  a  Geospatial-Node. 
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Every  Geospatial-Edge-Starting-Node 
is  a  Geospatial-Edge-Tenninal-Node. 
always  has  a  Geospatial-Node. 

Every  Geospatial-Edge-Terminal-Node 
may  be  either 

a  Geospatial-Edge-Ending-Node, 
or  a  Geospatial-Edge-Starting-Node, 
depending  on  Geospatial-Edge-Terminal-Node-Type-Code, 
always  has  a  Geospatial-Edge, 
always  has  a  Geospatial-Une-Terminal-Point. 

Every  Gcospadal-External-Boiinding-Closed-Line 
is  a  Geospatial -Surface-Region-Bounding-Qosed-Line. 

Every  Geospatial-External-Face-Ring 
is  a  Geospatial -Face-Ring. 

Every  Geospatial-Face 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial-Surface-Region . 
always  is  bounded  by  one  or  more  Geospatial-Face-Ring(s). 
always  Is  used  as  zero,  one  or  many  Geospatial-Shdl-Face(s). 

Every  Geospatial-Face-Ring 
may  be  either 

a  Geospatial-Exteraal-Face-Ring, 
or  a  Geospatial-Intemal-Face-Ring, 
depending  on  Geospatial-Face-Ring-Code, 
always  has  a  Geospatial-Face, 
always  has  a  Geospatial-Ring. 

Every  Geospatial-Feature 

always  establishes  die  type  of  zero,  one  or  many  Geospatial-Feature-Representation(s). 

Every  Geospatial-Featnre-Attribute 
always  has  a  Geospatial-Featiire-Attribate-Class. 
always  has  a  Geospatial-Feature-Representation. 

always  has  distribution  restricted  by  zero,  one  or  many  Country-Geospatial-Feature-Attribute- 
Rdease-Restriction(s). 

always  is  provided  one  or  more  Geoepstial-Feature-Attrfbute-Detail(s). 
always  is  assigned  one  or  mm  Oeospatial-Feature-Attribute-Security-ClassificatiosKs). 
always  has  distribution  restricted  by  zero,  one  or  many  Organ iration-Geospatial-Fcaturo-Attributo- 
Rdease-Restriction(s). 

Every  Geospatial-Feature-Attribute-Class 
always  describes  zero,  one  or  many  Geospatial-Feature-Attribute(s). 
always  is  die  basis  for  zero,  one  or  many  Geospatial-Feature- Attribute-Class-Qualifier(s). 
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Every  Geospatial-Feature- Attribute-Class-Qualifier 
always  has  a  Geospatial-Feature-Attribute-Class, 
always  defines  zero,  one  or  many  Geospatial-Feature-Attribute-Qualifier(s). 

Every  Geospatial-Feature- Attribute-Descriptor 
is  a  Geospatial-Feature-Attribute-Detail. 

Every  Geospatial-Feature-Attribute-Detail 
may  be  either 

a  Geospatial-Feature-Attribute-Descriptor, 
or  a  Geospatial-Feature-Attribute-Measurement, 
or  a  Geospatial-Feature-Attribute-Qualifier, 
depending  on  Geospatial-Feature-Attribute-Detail-Type-Code, 
always  has  a  Geospatial-Feature-Attribute. 

always  was  extracted  from  zero,  one  or  many  Geospatial-Feature- Attribute-Detail-Sour ce(s). 

Every  Geospatial-Feature-Attribute-Detail-Source 
always  has  a  Geospatial-Feature-Attribute-Detail, 
always  has  a  Geospatial-Source. 

Every  Geospatial-Feature-Attribute-Measurement 
is  a  Geospatial-Feature-Attribute-Detail. 

Every  Geospatial-Feature-Attribute-Qualifier 
is  a  Geospatial-Feature- Attribute-Detail . 
always  has  a  Geospatial-Feature-Attribute-Class-Qualifier. 

Every  Geospatial-Feature-Attribute-Security-Classification 
always  has  a  Geospatial-Feature-Attribute, 
always  has  a  Security-Classification. 

Every  Geospatial-Feature-Representation 
always  has  an  Organization, 
always  has  a  Geospatial-Feature. 

always  is  also  represented  by  zero,  one  or  many  Altemate-Geospatial-Feature-Representatk>n(s). 
always  is  identified  as  zero,  one  or  many  Alternate-Geospatial-Feature-Representation(s). 
always  is  a  composite  of  zero,  one  or  many  Component-GeospatUl-Feature-Representation(s). 
always  is  also  represented  by  zero,  one  or  many  Componem-Geospatial-Feature-Representation(s). 
always  has  distribution  restricted  by  zu o,  one  or  many  Country-Geospatiri-Feature-Represeniation- 
Release-Restriction(s). 

always  is  characterized  by  zero,  one  or  many  Geospatial-Feature-Attribute(s). 
always  is  composed  of  zero  or  one  Geospatial-Feature-Representation-Geometry(s). 
always  is  assigned  zero,  one  or  many  Geospatial-Fcaturo-Rcpresentation-Idcntification-Accuracyfs). 
always  is  classified  by  one  or  more  GeosptUial-Feature-Repmentation-Security-Classification(s). 
always  was  extracted  from  one  or  more  Geospatial-Feature-Representation-Source(s). 
always  undergoes  zero,  one  or  many  Geospatial-Feature-Reptt*eatation-Valkiation(i). 
always  has  distribution  restricted  by  zero,  one  or  many  Organization-Geospatial -Feature- 
Representatk>n-Release-Restriction(s ). 
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Every  Geospatial-Feature-Representation-Geometry 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial -Geometric-Element. 

always  is  assigned  zero  or  one  Geospatial-Feature-Representation-Vertical-Accuracy(s). 

Every  Geospatial-Feature-Representation-Identification-Accuracy 
always  has  a  Geospatial-Feature-Representation. 

Every  Geospatial-Feature-Represeataticn-Security-Classifi  cation 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Security-Classification. 

Every  Geospatial  -Feature-Representation-Source 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial -Source. 

Every  Geospatial-Feature-Representation-Validation 
always  has  a  Geospatial-Feature-Representation, 
always  has  an  Organization. 

Every  Geospatial-Feature-Representation-Vertical-Accuracy 
always  has  a  Geospatial-Feature-Representation-Geometry. 

Every  Geospatial-Geometric-Element 
is  a  Geospatial-Position-Element, 
may  be  either 

a  Geospatial-Line, 
or  a  Geospatial-Point, 
or  a  Geospatial -Surface-Region, 
depending  on  Geospatial-Geometric-Element-Type-Code. 
always  is  part  of  zero,  one  or  many  Geospatial-Feature-Repraentation-Geometryfs). 

Every  Geospatial-Intemal-Bounding-Closed-Line 
is  a  Geospatial-Surface-Region-Bounding-Closed-Line. 

Every  Geospatial-Intemal-Face-Ring 
is  a  Geospatial-Face-Ring. 

Every  Geospatial-Line 
is  a  Geospatial -Geometric-Element, 
may  be  a  Geospatial -Closed-Line, 
depending  on  Geospatial-Line-Closure-Code, 
always  is  die  locus  for  zero  or  one  Geospstial-Edge(s). 
always  is  defined  by  one  or  more  Geospadal-Line-Point(s). 
always  is  assigned  2  Geospatial-Line-Tenninal-Point(s). 


Every  Geospatial-Line-End  ing-Point 
is  a  Geospatial-Line-Terminal-Point, 
always  has  a  Geospatial-Line-Point. 
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Every  Geospatial-Line-Point 
always  has  a  Geospatial-Line, 
always  has  a  Geospatial-Point. 

always  serves  as  zero,  one  or  many  Geospatial  -Line-End  ing-Point(s) . 
always  serves  as  zero,  one  or  many  Geospatial-Line-Starting-Point(s). 

Every  Geospatial-Line-Starting-Point 
is  a  Geospatial-Line-Terminal-Point, 
always  has  a  Geospatial-Line-Point. 

Every  Geospatial-Line-Terminal-Point 
may  be  either 

a  Geospatial-Line-Ending-Point, 
or  a  Geospatial-Line-Starting-Point, 
depending  on  Geospatial-Line-Terminal-Point-Type-Code, 
always  has  a  Geospatial-Line. 

always  is  the  locus  of  zero,  one  or  many  Geospatial-Edge-Terminal-Node(s). 

Every  Geospatial-Node 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial-Point. 

always  serves  as  zero,  one  or  many  Geospatial -Edge-End  ing-Node(s). 
always  serves  as  zero,  one  or  many  Geospatial-Edge-Starting-Node(s). 

/ 

Every  Geospatial-Open-Path 
is  a  Geospatial-Path. 

Every  Geospatial-Path 
is  a  Geospatial-Topological-Element, 
may  be  either 

a  Geospatial-Open-Path, 
or  a  Geospatial-Ring, 
depending  on  Geospatial-Path-Type-Code, 
always  is  composed  of  one  or  more  Geospatial-Path-Edge(s). 

Every  Geospatial-Path-Edge 
always  has  a  Geospatial-Edge, 
always  has  a  Geospatial-Path. 

always  is  preceding  ring  edge  in  zero  or  one  Geospatial-Path-Edge-Sequence(s). 
always  is  succeeding  ring  edge  in  zero  or  one  Geospatial-Path-Edge-Sequence(s). 

Every  Geospatial-Path-Edge-Sequence 
always  has  a  Geospatial-Path-Edge, 
always  has  a  Geospatial -Path-Edge. 
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Every  Geospatial-Point 
is  a  Geospatial -Geometric-Element, 
always  serves  as  zero,  one  or  many  Geospatial -Line-Point(s) . 
always  is  the  location  of  zero  or  one  Geospatial-Nod e(s). 

always  has  its  third  dimension  provided  by  zero  or  one  Geospatial-Point-El evation(s). 

Every  Geospatial-Point-Elevation 
always  has  a  Geospatial-Point. 

Every  Geospatial-Position-Element 
may  be  either 

a  Geospatial-Geometric-Element, 
or  a  Geospatial-Topological-Element, 
depending  on  Geospatial-Position-Element-Type-Code, 
always  has  an  Organization. 

Every  Geospatial-Ring 
is  a  Geospatial-Path. 

always  is  used  as  zero,  one  or  many  Geospatial-Face-Ring(s). 

Every  Geospatial-Shell 
is  a  Geospatial-Topological-Element, 
always  is  composed  of  one  or  more  Geospatial-Shell-Face(s). 

Every  Geospatial-Shell-Face 
always  has  a  Geospatial-Face, 
always  has  a  Geospatial -Shell. 

Every  Geospatial-Source 

always  serves  as  zero,  one  or  many  Geospatial-Feature- Attribute-Detail-Source(s). 
always  serves  as  zero,  one  or  many  Geospatial-Feature-Representation-Source(s) . 

Every  Geospatial -Surface-Region 
is  a  Geospatial -Geometric-Element, 
always  is  die  locus  of  zero  or  one  Geospadal-Face(s). 

always  has  its  extent  bounded  by  one  or  more  Geospatial -Surface-Region-Bounding-Closed-Line(*). 

Every  Geospatial-Surface-Region-Bounding-Closed-Une 
may  be  either 

a  Geospatial-External-Bound  ing-Closed-Line, 
or  a  Geospatial-Intemal-Bounding-Closed-Line, 
depending  on  Geospatial -Surface-Region-Bounding-Ctosed-Line-Code. 
always  has  a  Geospatial -Closed-Line, 
always  has  a  Geospatial-Surface-Region. 
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Every  Geospatial-Topological-Element 
is  a  Geospatial-Position-Element, 
may  be  either 

a  Geospatial-Edge, 
or  a  Geospatial-Face, 
or  a  Geospatial-Node, 
or  a  Geospatial-Path, 
or  a  Geospatial-Shell, 

depending  on  Geospatial-Topological-Element-Type-Code. 

Every  Organization 

always  produces  zero,  one  or  many  Geospatial-Feature-Representation(s). 
always  validates  zero,  one  or  many  Geospatial-Feature*Representation-Validation(s). 
always  produces  zero,  one  or  many  Geospatial-Position-Elenient(s). 
always  is  part  of  zero,  one  or  many  Organization-Country(s). 

always  is  assigned  zero,  one  or  many  Organization-Geospadal-Feature-Attribute-Release- 
Restriction(s). 

always  is  assigned  zero,  one  or  many  Organization-Geospatial-Feature-Representation-Release- 
Restriction(s). 

Every  Organization-Country 
always  has  a  Country, 
always  has  an  Organization. 

/ 

Every  Organization-Geospatial -Feature- Attribute-Release-Restriction 
may  be  an  Organization-Geospatial-Feature-Attribute-Use-Constraint, 
depending  on  Organization-Geospatial-Feature-Attribute-Releasibility-Code. 
always  has  a  Geospatial-Feature-Attribute, 
always  has  an  Organization. 

Every  Organization-Geospatial-Feature-Attribute-Use-Constraint 
is  an  Organization-Geospatial-Feature-Attribute-Release-Restriction. 

Every  Organization-Geospatial-Feature-Representation-Rdease'Restrictkm 
may  be  an  Organization-Geospatial-Feature-Represezttation-Use-Constraint, 
depending  on  Organization-Goospatial-Fcature-Rcprcscmation-RelcasibOity-Codc. 
always  has  a  Geospatial-Feature-Representation, 
always  has  an  Organization. 

Every  Organization-Geospatial-Feature-Representation-Use-Constraint 
is  an  Organization-Geospatial-Feature-Ripresentation-Release-Restriction. 

Every  Security-Classification 

always  is  used  as  zero,  one  or  many  Geospatial-Feature-Attribute-Security-Classification(s). 
always  is  used  as  zero,  one  or  many  Geospatial-Feature-Represeotation-Security-Ciassification(i). 


The  DMA  fully  attributed,  normalized  model  is  on  pages  4-13  through  4-31.  The  glossary  begins  on 
page  4-33  and  is  followed  by  die  business  rules  on  page  4-50.  A  guide  to  reading  a  data  model  is 
located  in  Appendix  A. 

The  DMA  MC&G  Standardization  Pilot  Project  Data  Model  has  die  following  page  layout: 
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Fully  Attributed  Entity  Definitions 

ALTERNATE-GEOSPATIAL-EEATURE-REPRESENTAIION 

An  independent  model  of  a  geospatial  feature.  The  data  extraction  process  permits  capturing  different 
representations  of  die  same  real  world  object.  These  representations  are  related  to  each  other  through 
this  entity. 

COftCPONENT-GEOSPATIAI^FEATURE-REPRESENTATION 

A  geospatial  feature  representation  that  comprises  an  element  of  a  complex  geospatial  feature 
representation. 

COUNTRY 

A  sovereign  state.  Typically  an  autonomous  political  unit;  also  called  a  nation. 

This  entity  is  only  a  shadow  entity  in  the  DMA  Data  Model.  DMA  believes  it  is  not  responsible  for 
defining  and  modeling  the  entity  Country. 

COUNTRY-GEOSPATlAL-FEATURE'ATTRIBUTE-RELEASE'RESrFRICnON 

A  constraint  controlling  die  release  of  specific  data  about  a  geospatial  feature.  The  constraint  may 
prohibit  or  permit  said  release  to  a  country,  as  indicated  by  the  country  releasibility  attribute. 

COUNTRY-GEOSPAITALrFEATURE-ATTRIBlJTE-USE-CONSTRAINT 

The  limifafinne  to  die  use  a  receiving  country  may  make  of  specific  information  about  a  geospatial 
feature. 

COUNTRY^EOSPATIAL-FEATURE-REPRESENTATION-RELEASE-RESTRICTION 

A  constraint  controlling  the  release  of  a  geospatial  feature  representation.  The  constraint  may  prohibit 
or  permit  said  release  to  a  country,  as  indicated  by  die  country  releasibility  attribute. 

COUNTRY-GEOSPATIAL-FEATURE-REPRESENTATION-USE-CONSTRAINT 

The  limitation  to  die  use  a  receiving  country  may  make  of  a  geospatial  feature  representation. 

geospatiaix:losed-line 

A  non-self-intersecting  geospatial  line  specified  by  at  least  four  geospatial  points  in  which  die 
geospatial  line  starting  point  and  the  geospatial  line  ending  point  are  the  same. 
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GEOSPATIAL-EDGE 

A  one-dimensional  topological  element  bounded  by  one  geospatial  starting  node  and  one  geospatial 
ending  node  and  located  by  a  geospatial  line.  A  geosopatial  edge  is  directed  from  start  node  to  end 
node.  When  an  edge  is  a  part  of  a  more  complex  structure,  its  directionality  may  be  used  as  die  basis 
for  ideas  such  as  "right"  and  "left". 

GEOSPATIAL-EDGE-ENDING-NODE 

A  geospatial  node  identified  as  the  ending  node  of  a  geospatial  edge. 

GEOSPATIAL-EDGE-STARTING-NODE 

A  geospatial  node  identified  as  die  starting  node  of  a  geospatial  edge. 

GEOSPATIAL-EDGE-TERMINAL-NODE 

A  geospatial  node  which  is  either  the  starting  or  ending  node  for  a  specific  geospatial  edge. 
GEOSPATIAL-EXTERN AL-BOUNDING-CLOSED-LINE 

The  geospatial  surface  region  bounding  closed  line  which  defines  the  exterior  boundary  of  a  geospatial 
surface  region. 

GEOSPATIAL-EXTERNAL-FACE-RING 

The  geospatial  face  ring  which  defines  the  exterior  boundary  of  a  geospatial  face. 
GEOSPATIAL-FACE 

A  topological  region  enclosed  by  a  geospatial  ring.  A  geospatial  facehas  its  locus  defined  by  a 
geospatial  surface  region. 

GEOSPATIALFACE-RING 

The  geospatial  ring  which  is  a  boundary  of  a  geospatial  face.  The  ring  may  be  an  internal  boundary. 
The  ring  may  be  die  external  boundary. 

GEOSPATIALFEATURE 

An  identifiable  object  relative  to  die  Earth’s  surface.  A  wide  variety  of  identifiable  objects  exist  on 
and  sometimes  above  or  below  the  Earth’s  surface.  Included  among  these  are  moveable  or  temporal 
objects  (trucks,  command  posts,  etc.),  and  temporary  structures  (tents,  shelters,  etc.).  While  these 
are  of  interest  or  concern  from  many  perspectives,  the  geospatial  perspective  considers  only  those 
features,  natural  and  man-made,  that  remain  stationary  or  recur  in  die  same  place  over  a  significant 
length  of  time. 
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GEOSPATIAL-FEATURE-ATTRIBUTE 
A  characteristic  of  a  geospatial  feature. 

GEOSPATIAL-FEATURE-ATTRraUTE-CLASS 

The  generic  description  of  a  specific  geospatial  feature  attribute.  DIGEST  provides  a  list  of  attribute 
classes,  codes  and  descriptors  in  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  on  Page  4-6 
in  Section  4  for  a  fuller  understanding  of  how  the  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-CLASS-QUALIFIER 

Information  that  provides  further  detail  within  a  geospatial  feature  attribute  class  that  may  be  used  for 
geospatial  feature  characterization.  DIGEST  provides  the  lists  of  available  qualifier  (value)  codes  and 
descriptors  in  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  on  Page  4-6  in  Section  4  for  a 
fuller  understanding  of  how  die  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-DESCRIPTOR 

The  variable  length  text  string  providing  descriptive  detail  to  a  geospatial  feature  attribute  as  required 
by  die  attribute  class.  For  example,  die  feature  attribute  class  "Name”  requires  that  die  name  of  die 
feature  be  provided  as  a  text  string.  Refer  to  die  instance  tables  provided  on  Page  4-7  in  Section  4 
for  a  fuller  understanding  of  how  die  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-DETAIL 

/ 

Information  about  a  specific  geospatial  feature  that  provides  a  more  detailed  description  of  a 
geospatial  feature  attribute.  The  detail  is  one  of  three  types,  which  are  geospatial  feature  attribute 
descriptor,  geospatial  feature  attribute  measurement,  and  geospatial  feature  attribute  qualifier. 

DIGEST  Part  4  Annex  B  provides  a  list  of  standard  values  for  each  attribute.  Refer  to  the  instance 
tables  provided  on  Page  4-7  in  Section  4  for  a  fella  understanding  of  how  die  model  employs  these 
concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-DETAIL-SOURCE 

Information  about  a  specific  source  for  determining  a  geospatial  feature  attribute  detail. 

GEOSPATIAL-FEATURE-ATTRIBUTE-MEASUREMENT 

Hie  measured  value  of  a  specific  geospatial  feature  attribute.  Refer  to  die  instance  tables  provided  on 
Page  4-7  in  Section  4  for  a  fella  understanding  of  bow  die  model  employs  these  concepts. 

GEOSPATIAL-FEATURE-ATTRIBUTE-QUALIFIER 

The  specific  geospatial  feature  attribute  class  qualifia  used  to  provide  die  detail  description  of  a 
specific  geospatial  feature  attribute.  Refer  to  the  instance  tables  provided  on  Page  4-7  in  Section  4  for 
a  fella  understanding  of  how  die  model  employs  these  concepts. 
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GEOSPATIAIy-FEATURE-ATTRIBlJTE-SECURITY-CLASSIFICATlON 
A  security  classification  assigned  to  data  about  a  geospatial  feature  attribute. 
GEOSPATIAL-FEATURE-REPRESENTATION 

A  model  of  a  geospatial  feature.  The  model  provides  geometric  and  descriptive  characteristics  of  the 
feature.  The  geometric  portion  of  the  model  portrays  the  feature’s  size,  shape,  position  and 
connectivity  using  geometric  and  topologic  elements.  The  descriptive  portion  of  the  model  contains 
attribute  detail  descriptions,  attribute  qualifiers,  and  attribute  measurements. 

GEOSPATIAL-FEATURE-REPRESENTATION-GEOMETRY 

The  association  between  a  geospatial  feature  representation  and  its  geospatial  geometric  element. 

GEOSPATIAL-FEATURE-REPRESENTATION-IDENTIFICATION-ACCURACY 

The  probability  that  die  geospatial  feature  code  has  been  correctly  assigned  to  a  geospatial  feature 
representation. 

GEOSPATIAL-FEATURE-REPRESENTATION-SECURITY-CLASSIFICATION 

The  classification  assigned  to  a  geospatial  feature  representation. 

GEOSPATIAL-FEATURE-REPRESENTATION-SOURCE 

The  geospatial  source  from  which  information  about  a  geospatial  feature  was  extracted. 

GEOSPATIAL-FEATURE-REPRESENTATION-VALIDATION 

The  finding  that  a  geospatial  feature  representation  is  complete. 

GEOSPATIAL-FEATURE-REPRESENTATION-VERTICAL-ACCURACY 

Information  about  die  errors  associated  with  the  determination  of  the  elevation  of  geospatial  points 
used  in  die  geospatial  feature  representation  geometry. 

GEOSPATIAL-GEOMETRIC-ELEMENT 

A  component  of  a  geospatial  feature  representation  which  provides  information  about  size,  shape,  and 
position.  A  geometric  dement  may  have  a  topologic  dement  associated  with  it 

GEOSPATTAL-INTERNAL-BOUNDING-CLOSED-LINE 

A  geospatial  surface  region  bounding  dosed  line  used  as  an  interior  boundary  of  a  geospatial  surface 
region. 
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GEOSPATIAL-INTERNAL-FACE-RING 

A  geospatial  face  ring  used  as  an  interior  boundary  of  a  geospatial  face. 

GEOSPATIAL-LINE 

One  of  three  types  of  geometric  element,  defined  by  a  set  of  geospatial  points  in  an  ordered  sequence. 
The  defining  points  are  connected  by  straight  line  segments. 

GEOSPATIAL-LINE-ENDING-POINT 

A  geospatial  line  terminal  point  identified  as  die  last  point  in  a  sequence  of  points  that  defines  a 
geospatial  line. 

GEOSPATIAL-LINE-POINT 

A  geospatial  point  that  is  part  of  a  set  used  in  defining  a  geospatial  line. 
GEOSPATIAL-LINE-STARTING-POINT 

A  geospatial  line  terminal  point  identified  as  die  tint  point  in  a  sequence  of  points  that  defines  a 
geospatial  line. 

GEOSPATIAL-LINE-TERMINAL-POINT 

/ 

There  are  exactly  two  geospatial  points  designated  terminal  points  for  each  line.  One  geospatial  point 
is  a  terminal  end  point  and  one  is  a  terminal  start  point 

GEOSPATIAL-NODE 

A  zero  dimensional  topological  primitive  used  to  define  topologic  relationships.  A  geospatial  node  is 
always  associated  with  a  geospatial  point 

GEOSPATIAL-PATH 

A  set  of  edges  connected  at  their  terminal  nodes,  such  that  no  node  is  shared  by  more  than  two  edges 
of  die  set 

GEOSPATIAL-PATH-EDGE 

A  geospatial  edge  used  as  a  component  of  a  geospatial  path. 
GEOSPATIALrPATH-EDGE-SEQUENCE 

Information  about  die  order  of  the  assembly  of  a  geospatial  path.  This  entity  associates  a  geospatial 
edge  used  as  a  geospatial  path  edge  to  the  succeeding  geospatial  edge  in  the  path. 
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GEOSPATIAL-POINT 

The  zero  dimensional  primitive  that  assigns  the  geodetic  position.  Latitude,  longitude,  and  elevation, 
if  available,  are  defined  in  WGS  84.  (See  DMA  Technical  Report  8350.2.) 

GEOSPATIAL-POINT-ELEVATION 

A  geospatial  point  elevation  assigns  an  elevation  to  a  geospatial  point.  Hie  elevation  is  referenced  to 
mean  sea  level. 

GEOSPATIAL-POSITION-ELEMENT 

An  element  of  geometry  or  topology  used  for  real  or  conceptual  delineations  relative  to  die  surface  of 
the  earth.  Geometric  elements  include  geospatial  point,  geospatial  line,  and  geospatial  surface  region. 
Topologic  elements  include  geospatial  node,  geospatial  edge,  geospatial  face,  geospatial  shell,  and 
geospatial  path. 

GEOSPATIAL-RING 

A  closed  geospatial  path.  In  a  closed  geospatial  path,  every  geospatial  terminal  node  in  die  path  is 
shared  by  two  of  die  edges  that  make  up  die  path.  A  geospatial  ring  bounds  a  geospatial  face. 

GEOSPATIAL-SHELL 

An  open  connected  set  of  two  or  more  geospatial  faces. 

GEOSPATIAL-SHELL-FACE 

Information  that  a  specific  geospatial  face  is  a  member  of  a  set  that  composes  a  geospatial  shell. 
GEOSPATIAL-SOURCE 

Data  of  any  type  from  which  geospatial  feature  information  can  be  extracted.  Sources  include,  but 
are  not  limited  to,  ground  control,  aerial  and  terrestrial  photographs,  sketches,  maps,  and  charts; 
topographic,  hydrographic,  hypsographic,  magnetic,  geodetic,  oceanographic,  and  meteorological 
information;  intelligence  documents  and  written  reports  pertaining  to  natural  and  man-made  features 
of  the  area  to  be  mapped  or  charted. 

This  entity  is  only  a  shadow  entity  in  the  DMA  Data  Model.  DMA  believes  that  it  does  not  foil 
within  die  scope  of  this  project  to  define  and  model  the  entity  Geospatial-Source. 

GEOSPATIAL-SURF  ACE-REGION 

A  bounded  segment  of  a  specified  surface.  A  geospatial  surface  region  may  be  bounded  by  a 
geospatial  surface  region  dosed  line.  When  a  geospatial  surface  region  is  the  location  of  a  geospatial 
face,  the  loci  of  the  geospatial  edges  which  make  up  the  geospatial  face  ring  are  die  geospatial  lines 
which  bound  die  geospatial  surface  region. 
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GEOSPATIAL-SURFACE-REGION-BOUNDING-CLOSEEK-LINE 
A  geospatial  surface  region  closed  line  that  bounds  a  geospatial  surface  region. 
GEOSPATIAL-TOPOLOGICAL-ELEMENT 

A  primitive  that  defines  connectivity  and  relationship  of  die  parts  of  die  geospatial  position  elements. 
Every  topological  element  has  an  appropriate  association  to  a  geometric  element. 

OPEN-GEOSPATIAL-PATH 

A  geospatial  path  in  which  all  but  two  of  die  geospatial  nodes  are  shared  by  two  geospatial  edges. 
ORGANIZATION 

An  administrative  structure  constituted  to  accomplish  a  goal,  purpose  or  mission.  (Reference 
Working  Draft  of  DoD  Enterprise  Model;  February  1993.) 

This  entity  is  only  a  shadow  entity  in  die  DMA  Data  Model.  DMA  believes  it  is  not  responsible  for 
defining  mid  modeling  die  entity  Organization. 

ORGANIZATION-COUNTRY 

The  primary  association  between  an  organization  and  a  country.  The  association  is  used  to  determine 
disclosures  of  information,  limited  by  country.  , 

ORGANIZATION-GEOSPATIAL-FEATURE-ATTRIBUTE-RELEASE-RESTRICTION 

A  constraint  controlling  die  release  of  specific  geospatial  feature  attribute  data.  The  constraint  may 
prohibit  or  permit  said  release  to  an  organization,  as  indicated  by  die  country  rdeasibility  attribute. 

ORGANIZATION-GEOSPATTALrFEATURE-ATTRIBUTE'USE-CONSTRAINT 

The  limitations  to  the  use  a  receiving  organization  may  make  of  specific  information  about  a 
geospatial  feature  attribute. 

ORGANIZATTON-GEOSPATTAL-FEATURE-REPRESENTATTON-REX£ASE-RE?rRICTTON 

A  constraint  controlling  die  release  of  a  geospatial  feature  representation.  The  constraint  may  prohibit 
or  permit  said  release  to  an  organization,  as  indicated  by  die  organization  rdeasibility  attribute. 

ORGANIZATION-GEOSPATIAL-FEATURE-REPRESENTATION-USE-CONSTRAINT 

The  limitations  to  the  use  a  receiving  organization  may  make  of  a  geospatial  feature  representation. 

SECURITY-CLASSIFICATION 

Information  established  by  an  authoritative  body  about  a  level  of  control  of  information  disclosure. 
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Kev  Attribute  Definitions 

Alternate-Geo6patial-Feature-Reprtsentation-Iden  titter 

The  identifier  that  denotes  an  alternate  geospatial  feature  representation. 

Component-Geospatial-Feature-Representation-Identifier 

The  identifier  that  denotes  a  geospatial  feature  that  is  a  component  of  another  geospatial  feature 
representation. 

Composite-Geospatial-Feature-Representation-Iden  titter 

The  identifier  that  denotes  a  geospatial  feature  representation  that  contains  other  geospatial  feature 
representations  as  components. 

Country-Code 

The  code  that  denotes  a  country  as  specified  by  FIPS  PUB  10-3. 

Country-Geospatial-Feature-Attribute-Release-Restriction-Date 

The  date  on  which  a  country  geospatial  feature  attribute  release  restriction  was  established. 

Coimtry-GeospatUi-Feature-Representation-Release-Restriciioa-Date 

The  date  on  which  a  country  geospatial  feature  release  restriction  was  established. 

Geospatial-Closed-Iine-Identifier 

The  geospatial  line  identifier  that  denotes  a  geospatial  closed  line. 

Geospatial-Edge-Identifier 

The  geospatial  topological  dement  identifier  that  denotes  a  geospatial  edge. 
GeospatUl-Edge-Tenninal-Node-Type-Code 

The  code  that  denote  a  geospatial  edge  terminal  node  type.  The  type  may  be  a  geospatial  edge 
starting  node.  The  type  may  be  a  geospatial  edge  ending  node. 

Geospatial-Face-Idea  titter 

The  geospatial  topological  dement  identifier  that  denotes  a  geospatial  face. 
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Geospafial-Feature-Attribute-Class-Code 

The  code  that  denotes  a  geospatial  feature  attribute  class.  DIGEST  Part  4  Annex  B  provides  a  list  of 
standard  feature  attribute  codes. 

Geospatial-Feature-Attribute-Class-Qualifier-Code 

Hie  code  that  denotes  a  qualifier  of  the  selected  geospatial  feature  attribute  class.  DIGEST  Part  4 
Annex  B  provides  lists  of  standard  feature  attribute  qualifier  codes.  Refer  to  the  instance  tables 
provided  elsewhere  in  Section  4  for  a  fuller  understanding  of  how  die  model  employs  these  concepts. 

Geospatial-Feature-Attribute-Deiai  1-Identifier 

The  identifier  that  denotes  die  role  name  for  geospatial  feature  attribute  class  code,  geospatial  feature 
representation  producer  organization  identifier,  and  geospatial  feature  representation  identifier. 

Geospatial-Feature- Attribute-Detai  1-Sequence-Identi  tier 

The  sequence  identifier  that  distinguishes  between  several  geospatial  feature  attribute  descriptor  texts 
that  exist  for  die  same  geospatial  feature  attribute  detail  type  code. 

Geospatial-Feature-Attribute-Detail-Type-Code 

A  code  that  denotes  a  type  of  geospatial  feature  attribute  detail.  The  code  denotes  one  of  three  types 
of  geospatial  feature  attribute  detail,  which  are  geospatial  feature  attribute  descriptor,  geospatial 
feature  attribute  measurement,  and  geospatial  feature  attribute  qualifier. 

Geospatial-Feature-Attributo-Security-Classification-Effective-Date 

The  date  on  which  die  geospatial  feature  attribute  security  classification  was  established. 

Geospatial-Feature-Code 

The  code  that  denotes  a  specific  geospatial  feature  type.  Standard  codes  are  listed  in  DIGEST  Part  4 
Annex  A. 

Geospatial-Feature-Representation-Identifier 

The  identifier  that  uniquely  represents  a  geospatial  feature  representation  produced  by  a  specific 
geospatial  feature  representation  producer  organization. 

Geospatial-Feature-Representation-Identification-Accuracy-Effective-Date 

The  date  on  which  the  geospatial  feature  representation  identification  accuracy  was  assigned. 

Geospatial-Feature-Representatlon-Producer-Organizatlon-Identifier 

The  identifier  that  denotes  an  organization  as  die  producer  of  a  geospatial  feature  representation. 
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Geospa  tiat-Feature-Representation-Security-Classification-EfTective-Date 

The  date  on  which  the  geospatial  feature  representation  security  classification  was  established. 

Geospa  tial-Feature-Representation-Vali  da  tion-Date 

The  date  on  which  a  geospatial  feature  representation  validation  is  effective. 

GeospatiaHjeometric-Element-Identifier 

The  geospatial  position  element  identifier  that  denotes  a  geospatial  geometric  element.  It  is  die  role 
name  for  geospatial  position  element  producer  organization  identifier  and  geospatial  position  element 
identifier. 

Geospatial-Line-Identifier 

The  geospatial  geometric  element  identifier  that  denotes  a  geospatial  line. 
Geospatial-Line-Point-Sequence-Identifier 

The  identifier  that  denotes  die  position  of  a  specific  geospatial  line  point,  ordering  die  set  of 
geospatial  line  points  that  make  up  a  geospatial  line. 

Geospa  tlal-Llne-Terminal-Polnt-Type-Code 

/ 

The  code  thr  denotes  a  geospatial  line  terminal  point  type.  The  types  are  geospatial  line  starting 
point  and  geospatial  line  ending  point. 

Geospatial-Node-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  node. 
Geospatial-Path-Identifier 

The  geospatial  topological  element  identifier  that  represents  a  geospatial  path. 
Geospatial-Point-Identifier 

The  geospatial  geometric  element  identifier  that  denotes  a  geospatial  point. 
Geo6patial-Po6itioo-Elenient-Identifier 

The  identifier  that  denotes  a  specific  geospatial  position  element.  The  producer  organization  assigns  a 
unique  identifier  to  each  instance  of  geospatial  position  dement. 

Geospatial-Position-Elenient-Producer-Organization-Identifier 

The  organization  identifier  that  represents  a  geospatial  position  demon  producer  organization.  The 
organization  identifier  is  used  as  part  of  the  identification  of  a  geospatial  position  dement. 
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Geospatial-Preceding-Path-Edge-Identifier 

The  identifier  that  denotes  a  geospatial  edge  that  immediately  precedes  another  edge  in  the  sequence 
of  edges  that  make  up  a  path. 

Geos  pa  tia  (-Ring-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  ring. 

Geospatial-Shell-Identifier 

The  geospatial  topological  element  identifier  that  denotes  a  geospatial  shell. 
Geospatial-Source-Identifier 

The  identifier  that  denotes  data  of  any  type  from  which  geospatial  feature  information  can  be 
extracted.  The  identifier  will  be  more  clearly  defined  when  Source  is  modeled  more  completely. 

Geospa  tial-Surface-Region-Bounding-Closed-Iine-Code 

The  code  that  denotes  die  type  of  geospatial  surface  region  bounding  closed  line.  There  are  two 
types:  geospatial  external  bounding  closed  line  and  geospatial  internal  bounding  closed  line. 

Geospatial-Surface-Region-Identifier 

/ 

The  geospatial  geometric  element  identifier  that  denotes  a  geospatial  surface  region. 

Geospa  tial-Topological-Eleinent-Identiner 

The  geospatial  position  element  identifier  that  denotes  a  geospatial  topological  element.  It  is  foe  role 
name  for  geospatial  position  element  producer  organization  identifier  and  geospatial  position  dement 
identifier. 

Open-Geos  pa  tial-Patb-Identiner 

The  geospatial  topological  element  identifier  that  denotes  an  open  geospatial  path. 

Organization-Identifier 

The  identifier  that  denotes  an  organization. 

Organlzatioo-Geo6patial“Feature- Attribute-Release-Restriction-Date 

The  date  on  which  an  organization  geospatial  feature  attribute  release  restriction  was  established. 

Organizatioo-Geospatial-Feature-Representatioo-Release-Restriction-Date 

The  date  on  which  an  organization  geospatial  feature  representation  release  restriction  was  established. 
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Security-Classification-Code 

The  code  that  denotes  a  level  of  a  classification. 
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Non-Kev  Attribute  Definitions 

Country-Geospatial-Feature- Attribute-Releasi  b  i  li  ty-Code 

The  code  that  denotes  whether  a  country  can  receive  information  about  a  geospatial  feature  attribute. 
If  the  value  is  yes,  the  geospatial  feature  attribute  may  be  given  to  persons  or  organizations 
representing  that  country,  but  it  may  be  subject  to  constraints  expressed  by  die  organization  geospatial 
feature  attribute  release  restriction  and  country  geospatial  feature  attribute  use  constraint.  If  the  value 
is  no,  the  geospatial  feature  attribute  may  not  be  given  to  any  person  or  organization  representing  die 
country. 

Country  Geospatial-Feature-Attribute-Use-Constraint-Statement-Text 

The  text  identifying  the  limits  to  the  uses  a  receiving  country  may  make  concerning  the  geospatial 
feature  attribute. 

Country-Geospatial-Feature-Representation-Releasiblli  ty-Code 

The  code  that  denotes  whether  a  country  can  receive  a  geospatial  feature  representation. 

If  the  value  is  yes,  the  geospatial  feature  representation  may  be  given  to  persons  or  organizations 
representing  that  country,  but  it  may  be  subject  to  constraints  expressed  by  the  organization  geospatial 
feature  representation  release  restriction  and  country  geospatial  feature  representation  use  constraint. 
If  the  value  is  no,  the  geospatial  feature  representation  may  not  be  given  to  any  person  or 
organization  representing  the  country. 

Country  Geospatial-Feature-Represen  tation-Use-Constraint-Statement-Text 

The  text  identifying  the  limits  to  die  uses  a  receiving  country  may  make  concerning  die  geospatial 
feature  representation. 

Geospatial-Edge-Direction-Code 

The  code  that  denotes  the  direction  in  which  an  edge  is  traversed  when  that  edge  is  a  component  of  a 
geospatial  path.  Normal  traversal  of  a  geospatial  edge  is  from  geospatial  edge  starting  node  to 
geospatial  edge  ending  node.  When  an  edge  is  part  of  a  path,  it  may  be  traversed  in  die  opposite 
direction. 

Geospatial-Face-Ring-Code 

The  code  that  denotes  the  type  of  a  geospatial  face  ring.  There  are  two  types:  geospatial  external 
face  ring  and  geospatial  internal  face  ring. 

Geospatial-Feature- Attribute-Clag-Dfirription-Tcxt 

The  text  that  describes  the  geospatial  feature  attribute  class.  These  descriptions  are  provided  in 
DIGEST  Part  4  Annex  B.  Refer  to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  the  model  employs  these  concepts. 
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Geospatial-Feature-Attribute-Class-Name 

The  name  of  a  geospatial  feature  attribute  class.  A  list  of  these  names  is  provided  in  DIGEST  Part  4 
Annex  B.  Refer  to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller  understanding  of 
how  the  model  employs  these  concepts. 

Geospa  tial-Feature-Attribute-Class-Qualificr-Descriptio»-Text 

The  text  that  describes  a  geospatial  feature  attribute  class  qualifier.  These  descriptions  are  provided 
in  DIGEST  Part  4  Annex  B.  Refer  to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  the  model  employs  these  concepts. 

Geospatial-Feature-Attribute-Descriptor-Text 

The  text  of  die  geospatial  feature  attribute  descriptor  as  required  by  DIGEST  Part  4  Annex  B.  Refer 
to  the  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller  understanding  of  how  the  model 
employs  these  concepts. 

Geospatial-Feature-Attribute-Detail-Measured-Quantity 

The  quantity  of  die  measured  value  for  the  geospatial  feature  attribute  detail.  The  required  units  of 
measure  are  stated  in  DIGEST  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  elsewhere  in 
Section  4  for  a  fuller  understanding  of  how  die  model  employs  these  concepts. 

Geospatial-Feature-Attribute-Detail-IJnit-Of-Measure-Text 

The  text  describing  the  value  of  a  geospatial  feature  attribute  detail.  These  descriptions  are  provided 
in  DIGEST  Part  4  Annex  B.  Refer  to  die  instance  tables  provided  elsewhere  in  Section  4  for  a  fuller 
understanding  of  how  die  model  employs  these  concepts. 

Geospatial-Feature-Code-Definition-Text 

The  text  describing  die  distinguishing  characteristics  of  a  geospatial  feature. 
Geospatial-Feature-Represen  tatioo-Extracti  on-Date 

The  date  on  which  a  geospatial  feature  representation  was  produced  by  a  compilation  from  source 
data. 
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Geospatial-Feature-Representation-Horizontal-Accuracy-Qiiantity 

The  quantity  providing  circular  error  bounds  at  the  90%  confidence  level  for  die  geospatial  point 
horizontal  position. 

When  the  horizontal  position  of  an  identified  object  is  stated  in  latitude-longitude  measurements  (phi- 
lambda),  this  places  die  object  horizontally  with  respect  to  die  Earth’s  surface  in  an  Earth-centered 
fixed  coordinate  system.  The  error  associated  with  this  process  expresses  die  uncertainty  with  which 
the  phi-lambda  values  provided  are  correct. 

DMA  states  this  error  as  a  circular  error  (a  phi  =  a  lambda)  at  the  90%  confidence  level  indicating 
that  90%  of  die  placement  measurements  in  a  set  of  measurements  with  die  same  circular  error  will 
be  correct  to  within  die  radius  of  die  error  circle. 

Geospatial-Feature-Representation-Idaitirication-Acairacy-Percent-Quantity 

The  quantity  expressing  the  probability  that  die  geospatial  feature  code  has  been  correctly  assigned  to 
a  geospatial  feature  representation;  the  probability  is  expressed  as  a  percentage. 

Geospatial-Featiire-Representation-Validatiiig-Organizatioo-Identirier 

The  identifier  that  denotes  die  organization  that  validated  a  geospatial  feature  representation. 

Geospatial-Feature-Representation-Vertical- Accuracy-Quantity 

'  i 

The  quantity  providing  linear  error  bounds  at  the  90%  confidence  level  for  geospatial  point 
elevations. 

When  DMA  provides  a  vertical  measurement  positioning  an  object  with  respect  to  its  height,  above  or 
below  mean  sea  level,  die  measurement  is  accompanied  by  an  error  bound,  ±  a  h. 

The  interpretation  of  a  h  is:  In  a  set  of  vertical  measurements,  DMA  is  confident  that  90%  of  die 
stated  values  will  be  within  ±  a  h  of  the  true  value. 

Geospatial-Geometric-Eknient-Type-Code 

The  code  that  denotes  a  geospatial  geometric  dement  type.  There  are  three  types:  point,  surface 
region,  and  line. 

Geospatial-Iine^Iosuro-Code 

The  code  that  denotes  that  a  geospatial  line  is  a  geospatial  closed  line. 

Geospatial-Path-Type-Code 

The  code  that  denotes  the  type  of  a  geospatial  path.  There  are  two  types:  geospatial  ring  and  open 
geospatial  path. 
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Geospa  tiai-Point-Elevation-Dimension 

The  elevation  of  a  geospatial  point  in  meters  above  or  below  mean  sea  level. 
Geospatial-Point-Latitude-Coordinate 

One  of  tiie  coordinates  that  identifies  the  location  of  a  geospatial  point.  The  latitude  is  the  angle 
between  the  plane  of  the  geodetic  equator  and  the  normal  to  the  ellipsoid  at  a  point  (measured  positive 
north  from  the  geodetic  equator,  negative  south).  [DMA  Technical  Report  8350.2  -  WGS  84] 

Geospatial-Point-Longitude-Coordinate 

One  of  tiie  coordinates  that  identifies  the  location  of  a  geospatial  point.  The  longitude  is  the  angle 
between  the  plane  of  the  Zero  Meridian  and  tiie  plane  of  the  geodetic  meridian  of  tiie  point  (measured 
in  the  plane  of  tiie  geodetic  equator,  positive  from  0°  to  180°  E,  and  negative  from  0°  to  180°  W). 
[DMA  Technical  Report  8350.2  -  WGS  84] 

Geospatial-Position-Element-Extraction-Date 

The  date  on  which  a  geospatial  position  element  was  produced  by  a  compilation  from  source  data. 
Geospa  tial-Pasition-EIenient-Type-Code 

The  code  that  denotes  a  type  of  geospatial  position  dement.  The  type  may  be  a  geospatial  topological 
dement.  The  type  may  be  a  geospatial  geometric  dement. 

Geospatial-Succeeding-Path-Edge-Identifler 

The  geospatial  edge  identifier  that  denotes  a  geospatial  edge  that  immediately  succeeds  another 
geospatial  edge  in  the  sequence  of  geospatial  edges  that  make  up  a  geospatial  path. 

Geospatial-Topological-Elcment-Type-Code 

The  code  that  denotes  a  geospatial  topological  dement  type.  The  five  types  are:  shell,  face,  path, 
edge,  and  node. 

Organixatioo-Geospatlal-Feature-Attribute-Rdensibillty-Code 

The  code  that  denotes  whether  an  organization  can  receive  information  about  a  geospatial  feature 
attribute.  If  the  value  is  yes,  the  geospatial  feature  attribute  may  be  given  to  organizations  or 
persons  representing  those  organizations,  but  it  may  be  subject  to  constraints  expressed  by  die 
organization  geospatial  feature  attribute  rdease  restriction  and  country  geospatial  feature  attribute  use 
constraint  If  the  value  is  no,  the  geospatial  feature  attribute  may  not  be  given  to  any  organizations  or 
persons  representing  those  organizations. 
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Organization-Geos  pa  tiai-Feature-Attribute-Use-Constraint-Statement-Text 

A  text  that  describes  the  limits  to  the  uses  a  receiving  organization  may  make  concerning  die 
geospatial  feature  attribute. 

Organization-Geospa  tial-Feature-Representation-Releasibiiity-C  ode 

Hie  code  that  denotes  whether  an  organization  can  receive  a  geospatial  feature  representation.  If  die 
value  is  yes,  die  geospatial  feature  may  be  given  to  organizations  or  persons  representing  those 
organizations,  but  it  may  be  subject  to  constraints  expressed  by  the  organization  geospatial  feature 
representation  release  restriction  and  country  geospatial  feature  representation  use  constraint  If  the 
value  is  no,  die  geospatial  feature  representation  may  not  be  given  to  any  organizations  or  persons 
representing  dime  organizations. 

Organization-Geospatial-Feature-Representation-Use  Constraint-Statement-Text 

The  text  that  describes  the  limits  to  the  uses  a  receiving  organization  may  make  concerning  die 
geospatial  feature  representation. 
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Business  Rules 

Every  Alternate-Geospatial-Feature-Representation 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial-Feature-Representation. 

Every  Component-Geospatial-Feature-Representation 
always  has  a  Geospatial  -Feature-Representation . 
always  has  a  Geospatial-Feature-Representation. 

Every  Country 

always  is  assigned  zero,  one  or  many  Country-Geospatial-Feature-Attribute-Release-Restriction(s). 
always  is  assigned  zero,  one  or  many  Country-Geospatial-Feature-Representation-Release- 
Restriction(s). 

always  is  part  of  zero,  one  or  many  Organization-Country(s). 

Every  Country-Geospatial-Feature-Attribute-Release-Restriction 
may  be  a  Country-Geospatial-Feature-Attribute-Use-Constraint, 

depending  on  Country-Geospatial-Feature- Attribute-Releasibility-Code. 
always  has  a  Country, 
always  has  a  Geospatial-Feature-Attribute. 

Every  Country-Geospatial-Feature-Attribute-Use-Constraint 
is  a  Country-Geospatial-Feature-Attribute-Release-Restriction. 

/ 

Every  Country-Geospatial-Feature-Representation-Release-Restriction 
may  be  a  Country-Geospatial-Feature-Representation-Use-Constraint, 

depending  on  Country-Geospatial-Feature-Representation-Releasibility-Code. 
always  has  a  Country. 

always  has  a  Geospatial-Feature-Representation. 

Every  Country-Geospatial-Feature-Representation-Use-Constraint 
is  a  Country-Geospatial-Feature-Representation-Release-Restriction. 

Every  Geospatial-Closed-Line 
is  a  Geospatial-Line. 

always  is  used  as  zero,  one  or  many  Geospatial -Surfitte-Region-Bounding-Closed-Line(s). 

Every  Geospatial-Edge 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial-Line, 
always  is  assigned  2  Geospatial -Edge-Terminal  -Node(s) . 
always  is  used  as  zero,  one  or  many  Geospatial -Path-Edge(s) . 

Every  Geospatial-Edge-Ending-Node 
is  a  Geospatial-Edge-Terminal-Node, 
always  has  a  Geospatial-Node. 
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Every  Geospatial-Edge-Starting-Node 
is  a  Geospatial-Edge-Terminal-Node, 
always  has  a  Geospatial-Node. 

Every  Geospatial-Edge-Terminal-Node 
may  be  either 

a  Geospatial-Edge-Ending-Node, 
or  a  Geospatial-Edge-Starting-Node, 
depending  on  Geospatial-Edge-Terminal-Node-Type-Code, 
always  has  a  Geospatial-Edge, 
always  has  a  Geospatial-Line-Terminal-Point. 

Every  Geospatial-Extemal-Bounding-Closed-Line 
Is  a  Geospatial -Surface-Region-Bound  ing-Closed-Line. 

Every  Geospatial-External-Face-Ring 
is  a  Geospatial-Face-Ring. 

Every  Geospatial-Face 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial -Surface-Region, 
always  is  bounded  by  one  or  more  Geospatial-Face-Ring(s). 
always  is  used  as  zero,  one  or  many  Geospatial -Shell-Face(s). 

Every  Geospatial-Face-Ring 
may  be  either 

a  Geospatial-External-Face-Ring, 
or  a  Geospatial-Internal-Face-Ring, 
depending  on  Geospatial-Face-Ring-Code, 
always  has  a  Geospatial-Face, 
always  has  a  Geospatial-Ring. 

Every  Geospatial-Feature 

always  establishes  the  type  of  zero,  one  or  many  Geospatial-Feature-Representation(s). 

Every  Geospatial-Feature-Attribute 
always  has  a  Geospatial-Feature- Attribute-Class, 
always  has  a  Geospatial  -Feature-Representation. 

always  has  distribution  restricted  by  zero,  one  or  many  CounUy-Geospatial-Feature-Attribute- 
Release-Restriction(s) . 

always  Is  provided  one  or  more  Geospatial-Feature-Attribute-Detail(s). 
always  is  assigned  one  or  more  Geospatial-Feature- Attribute-Security-Clasaificatiop(t). 
always  has  distribution  restricted  by  zero,  one  or  many  Organization-Geospatial-Featuro-Attribute- 
Release-Restriction(s). 

Every  Geospatial-Feature-Attribute-Class 
always  describes  zero,  one  or  many  Geospatial-Feature- Attribute^), 
always  is  the  basis  for  zero,  one  or  many  Geospatial-Feature-Attribute-Qass-Qualifier(s). 
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Every  Geospatial-Feature-Attribute-Class-Qualifier 
always  has  a  Geospatial-Feature-Attribute-Class. 

always  defines  zero,  one  or  many  Geospatial-Feature-Attribute-Qualifier(s). 

Every  Geospatial-Feature-Attribute-Descriptor 
is  a  Geospatial-Feature-Attribute-Detail. 

Every  Geospatial-Feature-Attribute-Detail 
may  be  either 

a  Geospatial-Feature-Attribute-Descriptor, 
or  a  Geospatial-Feature-Attribute-Measurement, 
or  a  Geospatial-Feature-Attribute-Qualifier, 
depending  on  Geospatial-Feature-Attribute-Detail-Type-Code, 
always  has  a  Geospatial-Feature-Attribute. 

always  was  extracted  from  zero,  one  or  many  Geospatial-Feature-Attribute-Detail-Source(s). 

Every  Geospatial-Feature-Attribute-Detail-Source 
always  has  a  Geospatial -Feature- Attribute-Detail . 
always  has  a  Geospatial-Source. 

Every  Geospatial-Feature-Attribute-Measurement 
is  a  Geospatial-Feature- Attribute-Detail. 

Every  Geospatial-Feature-Attribute-Qualifier 
is  a  Geospatial-Feature- Attribute-Detail . 
always  has  a  Geospatial-Feature-Attribute-Class-Qualifier. 

Every  Geospatial-Feature-Attribute-Security-Classification 
always  has  a  Geospatial-Feature-Attribute, 
always  has  a  Security-Classification. 

Every  Geospatial-Feature-Representation 
always  has  an  Organization, 
always  has  a  Geospatial-Feature. 

always  is  also  represented  by  zero,  one  or  many  Alternate-Geospatial-Feature-Representation(s). 
always  is  identified  as  zero,  one  or  many  Altemate-Geospatial-Feature-Representatk)n(s). 
always  is  a  composite  of  zero,  one  or  many  Componem-Geospatial-Feature-Repiesentatk>n(s). 
always  is  also  represented  by  zero,  one  or  many  Component-Geospatial-Feature-Representation(s). 
always  has  distribution  restricted  by  zero,  one  or  many  Country -Geospatial -Feature-Representation- 
Release-Restriction(s) . 

always  is  by  zero,  one  or  many  Geospatial-Feature- Attributed), 

always  is  composed  of  zero  or  one  Geospatial-Feature-Representation-Geometry(s). 
always  is  assigned  zero,  one  or  many  Geospatial-Feature-Representation-Identification-Accuncy(s). 
always  is  classified  by  one  or  more  Geospatial-Feature-Repitsentation-Security-Classification(s). 
always  was  extracted  from  one  or  more  Geospadal-Feature-Representation-Source(s). 
always  undergoes  zero,  one  or  many  Geospatial-Feature-Representatk>n-Validatkm(s). 
always  has  distribution  restricted  by  zero,  one  or  many  Organization-Geospatial-Feature- 
Representatk>n-Release-Restrictk>n(s ). 
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Every  Geospatial-Feature-Representation-Geometry 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial-Geometric-Element. 

always  is  assigned  zero  or  one  Geospatial-Feature-Representation-Vertical-Accuracy(s). 

Every  Geospatial-Feature-Representation-Identifi  cation-Accuracy 
always  has  a  Geospatial-Feature-Representation. 

Every  Geospatial-Feature-Representation-Security-Classification 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Security-Classification. 

Every  Geospatial-Feature-Representation-Source 
always  has  a  Geospatial-Feature-Representation, 
always  has  a  Geospatial-Source. 

Every  Geospatial-Feature-Representation-Validation 
always  has  a  Geospatial-Feature-Representation, 
always  has  an  Organization. 

Every  Geospatial-Feature-Representation-Vertical-Accuracy 
always  has  a  Geospatial-Feature-Representation-Geometry. 

Every  Geospatial-Geometric-Element 
is  a  Geospatial-Position-Element, 
may  be  either 

a  Geospatial-Line, 
or  a  Geospatial-Point, 
or  a  Geospatial-Surface-Region, 
depending  on  Geospatial -Geometric-Element-Type-Code, 
always  is  part  of  zero,  one  or  many  Geospatial-Feature-Representation-Geometry(s). 

Every  Geospatial-Internal-Bound ing-Closed-Line 
is  a  Geospatial  -Surface-Region-Bounding-Closed-Line . 

Every  Geospatial-Intemal-Face-Ring 
is  a  Geospatial-Face-Ring. 

Every  Geospatial-Line 
is  a  Geospatial-Geometric-Element, 
may  be  a  Geospatial-Closed-Line, 
depending  on  Geospatial-Line-Closure-Code, 
always  is  die  locus  for  zero  or  one  Geospadal-Edge(s). 
always  is  defined  by  one  or  more  Geospkial-Line-Point(s). 
always  is  assigned  2  Geospatial-Line-Terminal-Point(s). 


Every  Geospatial-Line-Ending-Point 
is  a  Geospatial-Line-Terminal-Point. 
always  has  a  Geospatial-Line-Point. 
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Every  Geospatial-Line-Point 
always  has  a  Geospatial-Line, 
always  has  a  Geospatial-Point. 

always  serves  as  zero,  one  or  many  Geospatial-Line-Ending-Point(s). 
always  serves  as  zero,  one  or  many  Geospatial-Line-Starting-Point(s). 

Every  Geospatial-Line-Starting-Point 
is  a  Geospatial -Line-T erminal  Point . 
always  has  a  Geospatial-Line-Point. 

Every  Geospatial-Line-Terminal-Point 
may  be  either 

a  Geospatial-Line-Ending-Point, 
or  a  Geospatial-Line-Starting-Point, 
depending  on  Geospatial-Line-Terminal -Point-Type-Code, 
always  has  a  Geospatial-Line. 

always  is  the  locus  of  zero,  one  or  many  Geospatial-Edge-Terminal-Node(s). 

Every  Geospatial-Node 
is  a  Geospatial-Topological-Element, 
always  has  a  Geospatial-Point. 

always  serves  as  zero,  one  or  many  Geospatial-Edge-Ending-Node(s). 
always  serves  as  zero,  one  or  many  Geospatial-Edge-Starting-Node(s). 

Every  Geospatial -Open-Path  ' 

is  a  Geospatial-Path. 

Every  Geospatial-Path 
is  a  Geospatial-Topological-Element, 
may  be  either 

a  Geospatial -Open-Path, 
or  a  Geospatial-Ring, 
depending  on  Geospatial-Path-Type-Code, 
always  is  composed  of  one  or  more  Geospatial-Path-Edge(s). 

Every  Geospatial-Path-Edge 
always  has  a  Geospatial-Edge, 
always  has  a  Geospatial-Path. 

always  is  preceding  ring  edge  in  zero  or  one  Geospatial-Path-Edge-Sequence(s). 
always  is  succeeding  ring  edge  in  zero  or  one  Geospadal-Path-Edge-Sequence(s). 

Every  Geospatial-Path-Edge-Sequence 
always  has  a  Geospatial-Path-Edge, 
always  has  a  Geospatial-Path-Edge. 
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Every  Geospatial-Point 
is  a  Geospatial-Geometric-Element, 
always  serves  as  zero,  one  or  many  Geospatial-Line-Point(s). 
always  is  the  location  of  zero  or  one  Geospatial-Node(s). 

always  has  its  third  dimension  provided  by  zero  or  one  Geospatial-Point-El evation(s). 

Every  Geospatial-Point-Elevation 
always  has  a  Geospatial-Point. 

Every  Geospatial-Position-Element 
may  be  either 

a  Geospatial-Geometric-Element, 
or  a  Geospatial-Topological  -El  ement, 
depending  on  Geospatial-Position-Element-Type-Code, 
always  has  an  Organization. 

Every  Geospatial-Ring 
is  a  Geospatial-Path. 

always  is  used  as  zero,  one  or  many  Geospatial-Face-Ring(s). 

Every  Geospatial-Shell 
is  a  Geospatial-Topological-Element, 
always  is  composed  of  one  or  more  Geospatial-Shell-Face(s). 

Every  Geospatial-Shell-Face 
always  has  a  Geospatial-Face, 
always  has  a  Geospatial-Shell. 

Every  Geospatial-Source 

always  serves  as  zero,  one  or  many  Geospatial-Feature-Attribute-Detail-Source(s). 
always  serves  as  zero,  one  or  many  Geospatial-Featuro-Rcprescntation-Source(s). 

Every  Geospatial-Surface-Region 
is  a  Geospatial-Geometric-Element, 
always  is  the  locus  of  zero  or  one  Geospatial-Face(s). 

always  has  its  extent  bounded  by  one  or  more  Geospatial-Surface-Region-Bounding-Closed-Line(s) . 

Every  Geospatial-Surface-Region-Bounding-Closed-Line 
may  be  either 

a  Geospatial  -External  -Bound  ing-Closed-Line, 
or  a  Geospatial-Intemal-Bound ing-Closed-Line, 
depending  on  Geospatial-Surface-Region-Bound ing-Closed-Line-Code. 
always  has  a  Geospatial -Closed-Line, 
always  has  a  Geospatial-Surface-Region. 
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Every  Geospatial-Topological-Element 
is  a  Geospatial-Position-Element, 
may  be  either 

a  Geospatial-Edge, 
or  a  Geospatial-Face, 
or  a  Geospatial-Node, 
or  a  Geospatial-Path, 
or  a  Geospatial-Shell, 

depending  on  Geospatial-Topological-Element-Type-Code. 

Every  Organization 

always  produces  zero,  one  or  many  Geospadal-Feature-Representation(s). 
always  validates  zero,  one  or  many  Geospatial-Feature-Representation-Validation(s). 
always  produces  zero,  one  or  many  Geospatial-Position-Element(s). 
always  is  part  of  zero,  one  or  many  Organization-Country (s). 

always  is  assigned  zero,  one  or  many  Organization-Geospatial-Feature-Attribute-Release- 
Restriction(s). 

always  is  assigned  zero,  one  or  many  Organization-Geospatial-rsature-Representation-Re^Jse- 
Restricdon(s). 

Every  Organization-Country 
always  has  a  Country, 
always  has  an  Organization. 

f 

Every  Organization-Geospatial-Feature-Attribute-Release-Restriction 
may  be  an  Organization-Geospatial-Feature-Attribute-Use-Constraint, 

depending  on  Organization-Geospatial-Feature-Attribute-Releasibility-Code. 
always  has  a  Geospatial-Feature-Attribute, 
always  has  an  Organization. 

Every  Organization-Geospatial-Feature-Attribute-Use-Constraint 
is  an  Organization-Geospatial-Feature-Attribute-Release-Restriction. 

Every  Organization-Geospatial-Feature-Representation-Release-Restriction 
may  be  an  Organization-Geospatial-Feature-Representation-Use-Constraint, 
depending  on  Organization^ eospatial-Featoe-Representation-Releasibility-Code. 
always  has  t  Geospatial-Feature-Representation . 
always  has  an  Organization. 

Every  Organization-Geospatial  -F eature-Repr esentation-Use-Constraint 
is  an  Organization-Geospatial-Feature-Representation-Release-Restriction. 

Every  Security-Classification 

always  is  used  as  zero,  one  or  many  G eospatial -Feature- Attribute-Security-Cl ass ification(s). 
always  is  used  as  zero,  one  or  many  Geospatial-Feature-Representation-Security-Classification(s). 
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FAX 

TO: 

IrisKameny 

FAX  310393-4818 

4  Feb  94 

FROM: 

Beth  Driver 

FAX  703285*9396 

Voice  703285-9222 

SUBJECT: 

Discussion  topics  for  Complex  Data  Task  Force 

Iris— 

Here  are  a  couple  topics  Td  be  interested  in  having  the  Complex  Data  Task  Force  discuss.  I 
gather  from  our  discussion  that  toe  group  may  have  already  identified  them. 

•  What  Is  the  relationship  between  meta-data  tor  "instance  data"  (as  I  think  you  are 
using  toe  term— things  like  specific  features  or  attributes)  and  that  for  "wholes"  that 
represent  a  larger  picture,  not  merely  an  aggregate  of  features.  I  have  used  the 
example  of  a  map  or  digital  data  set  that  purports  to  be  a  picture  of  selected  aspects 
of  a  geographic  area.  One  reason  tor  concern:  we  draw  conclusions  about  toe 
absence  of  data  and  toe  relationships  between  features  from  the  whole,  not  form  the 
Individual  features.  For  example,  u  I  see  no  accesses  to  s  limited  access  highway 
between  two  locations ,  I  would  conclude  they  don't  exist- 1  would  suggest  that 
"completeness"  measures,  for  example,  (often  considered  a  part  of  currency 
evaluations  of  MC&G  data)  need  a  well-defined  footprint,  as  do  any  "truth  in 
packaging"  items  that  are  based  on  sampling  or  statistical  analysis. 

•  How  can  we  verify  tire  usefulness  of  metadata  definitions;  for  example,  how  will 
applications  software  use  toe  data  provided  in  metadata  fields?  Perhaps  generating 
sample  values  would  help  us  understand  and  organize  this. 

•  How  much  (at  what  level  of  granularity)  metadata  can  MAS  systems  process?  What 
are  toa  priorities?  Is  totre  a  nttd  for  selected  attributes  at  hlghdsgroee  of  granularity 
(e.g.,  attribute  level  for  some  attributes)  and  other  attributes  only  at  a  more 
generalized  level,  even  though  It  would  be  possible  to  provide  them  at  the  instance  level. 
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CHAPTER  1 
INTRODUCTION 


A.  PURPOSE 

1 .  This  document  describes  management  guidelines  and  logical  data  models  for 

capturing  and  sharing  information  about  four  categories  of  complex  data  elements  and  data 
concepts: 


a.  Composite  Data  Elements.  Data  elements  that  embed  intelligence  about 
multiple  concepts  in  their  names,  definitions,  and  domains. 

b.  Derivations.  Data  elements  representing  concepts  computed,  aggregated, 
transformed,  or  inferred  from  the  values  of  one  or  more  other  data  elements. 

c.  Data  Streams,  Ordered  bits  or  characters  formatted  to  represent  information 
in  a  variety  of  forms  (e.g.,  graphic,  voice,  text  document,  and  spreadsheet). 

d.  Assemblies.  Data  entities  comprising  instances  of  data  which  relate  to  other 
instances  of  data  within  the  same  entity  (e.g.,  roads,  buildings,  equipment  part  assemblies,  and 
organizations). 

2.  The  models  presented  can  capture  information  needed  to: 

a.  Improve  organizational  awareness  of  how  data  elements  in  these  categories 

are  related. 


b.  Reduce  the  amount  of  time  it  takes  new  people  to  become  aware  of 
relationships  among  complex  data. 

c.  Enhance  communications  across  functional  boundaries  sharing  complex 

data. 


d.  Foster  the  use  of  'standard  information  parts’  for  the  assembly  of  databases, 

information  systems,  and  information  sharing  transactions 
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e.  Support  migration  of  legacy  systems  and  information  sharing  made  possible 
by  new  applications,  hardware  platforms,  and  design  methodologies. 

3.  Relational  data  models  are  used  to  depict  the  models.  These  are  not  endorsed  as  die 
'best'  diagramming  techniques  for  representing  complex  data,  but  are  used  here  because  die 
majority  of  die  audience  is  familiar  with  relational  modeling  semantics  and  syntax.  The  relational 
models  can  also  be  used  to  design  repositories  for  capturing  facts  about  complex  data  using 
currently  prevalent  relational  database  technology. 

B.  DOCUMENT  ORGANIZATION 

This  document  can  be  read  sequentially,  or  be  used  as  a  quick  reference  for 

1 .  Composite  Data  Elements  (Chapter  2). 

2.  Derivations  (Chapter  3). 

3.  Data  Streams  (Chapter  4). 

4.  Assemblies  (Chapter  5). 
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CHAPTER  2 

COMPOSITE  DATA  ELEMENTS 


A. 


•JSOICIIKW 


1 .  Composite  data  elements  describe  multiple  concepts  by  coding  intelligrnoe 
into  the  individual  data  element  values,  embedding  domain  values  among  words  used  to 
name  die  data  element,  and/or  making  the  definition  or  meaning  of  die  data  element 
dependent  on  die  value(s)  contained  in  other  related  data  element(s). 

2.  When  elements  are  formulated  as  composites,  associations  develop  among 
data  elements  supporting  different  requirements.  A  data  element  association  is  a 
relationship  among  two  or  more  data  elements  due  to  a  partial  overlap  in  definition,  or  due 
to  important  characteristics  or  business  rules  concerning  the  group  (e.g.,  when  considered 
individually,  each  element  in  a  group  may  be  unclassified,  but  taken  as  a  whole,  the  group 
may  cany  classified  information). 

B.  CLASSIFICATION  OF  COMPOSITE  ELEMENTS 


The  National  Institute  of  Standards  and  Technology  Special  Publication  500-208,  Manual 
for  Data  Administration  /reference  fgll  defines  dime  fvpr*  nf  enmpnrite  data  p™eecci«£ 
identified  in  Figure  2-1: 


1  •  Cham,  An  ordered  set  of  data  elements  linked  together  (e.g.,  positions  1-3  describe 
concept  "A",  positions  4-5  describe  concept  "B",  etc.).  For  example,  consider  a  ‘Policy 
Identifier’  formulation  where  positions  1  through  7  identify  a  customer,  positions  8  through  10 
identify  the  type  of  policy,  positions  11  and  12  identify  the  year  the  policy  started,  and  positions  13 
and  14  identify  die  expiration  date. 

2.  Coupled.  A  data  element  carrying  multiple  concepts  through  its  assigned  name,  or 
its  allowable  set  of  coded  values.  For  example,  the  data  element  Tour  Passenger  Automobile 
Count’  not  only  describes  the  number  of  cars,  but  also  describes  the  type  of  ear  (passenger)  and 
the  seating  capacity  (four). 
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Association 


Description 


Chain 


Standard  is  a  member  of  Chain  Composite 


An  ordered  set  of  data  elements  linked  together  (e.g.,  positions 
1-3  =>  concept  'A',  positions  4-5  =>  concept  3',  etc.). 


Standard  Participates  in  Coupling  Composite 

A  data  element  describing  more  than  a  single  concept  (Le.,  two  or 
more  concepts  are  bundled  in  a  single  data  element). 


Muli-Purpose 


L 


Implemented  Element  has  Multiple  Uses,  Each  Supporting  a 
Different  Standard 

A  data  element  with  multiple  uses  or  definitions  (Le.,  the  mining 
changes  based  on  what  is  described  by  the  record). 


Legend 


Data  Element 


QFopnnlahnn  Coofonns  with  Guidelines 
for  One  Concept  and  One  Use 


Foanolaaons  That  Fail  to  Conform  with 
Gniddmea  for  One  Concept  and  One  Use 


O  -Concept 


Figure  2-1  Common  Types  of  Associations  Between  Data  Elements 
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3.  Multi-purpose.  A  data  element  with  multiple  uses  or  definitions.  The  context  of  the 
value  contained  in  the  data  element  changes  based  on  what  is  described  by  the  record.  For 
example,  the  value  "5"  in  the  data  element  ‘Vehicle  Capacity’  might  mean  "five  passengers"  for  a 
passenger  car,  but  mean  "five  tons"  for  a  delivery  truck. 

C.  CHAINED  DATA  ELEMENTS 

1 .  A  data  element  chain  is  fanned  by  physically  concatenating  two  or  more 
data  elements,  and  then  naming,  implementing,  and  managing  die  collective  group  as  a 
single  data  element  This  happens,  as  suggested  in  Figure  2-2,  when  a  values  for  a  data 
element  are  coded  so  that  different  types  of  information  are  carried  in  different  positions  of 
the  code.  Partial  redundancy  occurs  across  chains  when  a  single  concept  data  element  is 
carried  in  two  or  more  chains. 

2.  There  arc  times  when  the  order  of  concepts  concatenated  into  a  chain 
represents  an  institutionalized  standard  for  exchanging  data,  or  for  identifying  individual 
records  in  a  table  containing  data  that  are  widely  shared.  For  example.  National  Stock 
Number  (NSN)  is  a  chain  which  can  be  decomposed  into  three  primitive  elements  shown  in 
Figure  2-3.  NSN  is  a  concatenation  of  Federal  Supply  Classification  and  National  Item 
Identification  Number.  The  Federal  Supply  Classification  can  be  further  decomposed  into 
Federal  supply  Group  and  Federal  Supply  Subgroup.  If  all  systems  treat  NSN  as  die  same 
concatenation  of  these  concepts  for  accessing  or  exchanging  data,  then  chain  should  be 
documented  and  coordinated  as  a  standard  for  improving  data  sharing/data  exchange. 

3.  Concepts  concatenated  into  a  chain  must  be  modeled  as  single  concept 
elements.  A  chained  data  element  can  easily  be  decomposed  into  its  smaller  components, 
and  when  this  is  done,  die  redundancy  is  easier  to  detect 

4.  Chains  are  allowed  in  databases,  but  the  decision  on  whether  or  not  to 
develop  and  implement  a  chain  for  a  specific  combination  must  be  managed  as  a 
coordinated  implementation  issue.  If  the  components  of  the  chain  do  not  have  independent 
uses  outside  of  the  chain,  then  there  is  a  strong  business  case  for  implementing  die  e ham 

5.  Chains  are  allowed  in  data  exchange  transactions  (e.g..  Electronic  Data 
Interchange  (EDI)  transactions,  and  Message  Text  Formats  (MTFs));  However, 
responsibility  must  be  assigned  for  developing,  maintaining,  and  operating  software  for 
producing  the  agreed  upon  exchange  transaction  in  the  memorandum  of  agreement.  The 
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Principle 


Example 

Name:  Command  and  Control  Number  (CCNUM) 

Psn  1-2:  Major  Command  Code 

Psn  3-4:  Document  Version  Number 

Psn  5-6:  Fiscal  Year 

Name:  Modified  Table  of  Organization  and  Equipment  Code  (MTOEC) 

Psn  1-6  Base  Table  of  Organization  and  Equipment 
Psn  7-8  Major  Command  Code 

Psn  9-10  Modification  Number 


Redundancy  of  Concept  "A  "  is  masked  by  its  linkages 


Unchained  Data  Element 

Names: 

Sbn 

M^or  Command  Code 

©  \j 

Document  Version  Number 

©  \! 

Fiscal  Year 

m  i 

Base  Table  of  Organisation  and  Equipment 

*  Redundancy  of  Concept  "A"  is  apparent  after  die  chained  data 

•  elementts  are  decomposed  into  single  concepts. 

Figure  2-2  Partially  Overlapping  Data  Element  Chains 
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organization  assuming  these  cost  responsibilities  must  consent  to  the  terms  of  the 
agreement 

6 .  Chains  will  be  documented  in  the  DDRS,  to  include  the  association  of  die 
individual  elements  participating  in  die  chain.  This  documentation  will: 

a.  Allow  requirements  for  individual  elements  participating  in  die  chain 
to  be  easily  registered. 

b.  Support  efforts  to  migrate  legacy  chains  to  single  concept  elements. 

7 .  If  a  requirement  is  registered  for  an  individual  element  participating  in  a 
chain  documented  for  database  implementation,  the  implementation  decision  must  then  be 
revisited. 

D.  COUPLED  DATA  ELEMENTS 

1 .  Data  elements  are  often  constructed  to  cany  intelligence  in  their  names  or  in 
their  coded  values.  When  a  data  element  catties  information  about  more  than  one  thing,  it 
is  a  coupled  data  element  A  coupled  data  element’s  definition  can  partially  overlap  with  the 
definition  of  another  data  element  by  sharing  only  some  of  the  concepts  it  characterizes. 
Because  the  overlap  is  partial,  redundancy  across  the  elements  is  masked. 

2.  A  trivial  example  association  of  coupled  data  elements  is  shown  in  Figure  2- 
4  to  illustrate  data  coupling.  Coupled  data  elements  in  tire  upper  half  of  this  Figure  arc 
from  a  system  designed  to  support  force  structuring.  They  all  share  die  concept  'strength 
count',  but  differ  in  the  resource  code  (Le.,  types  of  personnel  such  as  officer,  warrant 
officer,  enlisted,  etc.)  to  which  the  strength  count  applies,  and  the  type  of  strength  (Le., 
Structured  or  authorized).  Many  new  entries  can  he  made  into  this  list  of  partially 
overlapping  data  elements  simply  by  defining  new  resource  codes  and/or  new  types  of 
strength  and  plugging  them  into  the  data  element  name*. 

3.  The  resource  code,  and  its  values,  shown  in  the  lower  half  of  Figure  2-4 
also  exist  in  the  budgeting  system.  It  is  not  intuitively  clear  how  data  relate  across  the  two 
systems  until  the  coupled  data  elements  in  the  force  structuring  system  are  broken  down  to 
single  concept  formulations  (Le.,  they  are  cohesive)  used  in  tire  budgeting  system. 

4.  The  example  in  Figure  2-4  is  a  trivial  example  used  to  illustrate  coupling 
and  its  attendant  problems.  Coupling  two  concepts  into  an  element  does  not  necessarily 
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a.  Coupled  Data  Elements 

Principle 

Concepts 
Bundled 


Redundancy 

Masked 


Example 

Authorized  Officer  Strength 
Authorized  Warrant  Officer  Strength 
Authorized  Enlisted  Strength 
Authorized  Civilian  U.S.  Direct  Hire  Strength 
Authorized  Civilian  Foreign  National  Strength 
Authorized  Civilian  Indirect  Hire 
• 

etc? 


b.  Cohesive  Data  Elements 

Principle 

r  Concepts 
Granular 

©  ©CD 

_ Redundancy 

Apparent 


Example 

Budget  Status  Code 
Resource  Code 
Strength  Quantity^ 

• 

Three  data  elements  -and  only 
three  data  elements 


Figure  2-4  Coupled  Concepts  Within  A  Single  Element 
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result  in  a  poor  formulation.  There  is  a  risk  for  problems  occurring  that  increases  as  the 
number  of  concepts  bundled  into  the  element  increase.  The  risk  for  problems  occurring 
also  increases  when  the  data  element  is  to  support  new  or  unstable  requirements. 

5 .  The  DoD  data  standardization  program  focuses  on  encouraging  database 
rWignc  to  adopt  data  elements  that  describe  singular  concepts  (e.g.,  establishing  data 
element  naming  conventions  that  require  a  single  prime  word  for  the  concept  described,  and 
single  class  word  for  die  use).  A  data  element  that  describes  a  single  concept  is  more 
familiar  to  the  users  because  it  is  easier  to  name  and  describe  what  values  should  be  put  into 
die  elffflfnt  A  single-concept  data  element  is  also  more  stable  than  its  multi-concept 
counterpart  bcc-aure  it  is  not  impacted  by  changes  to  other  data  elements.  When  a  single¬ 
concept  element  needs  to  be  changed,  it's  own  modularity  makes  die  scope  of  the  change 
smaller;  the  change  encompasses  only  one  element  rather  than  cascading  to  other  data 
rlrmrnt*  with  partially  overlapping  definitions.  The  single-concept  data  element  is  more 
flexible  than  its  multi-purpose  counterpart  because  it  supports  a  wide  range  of  usage  across 
functional  boundaries. 

6.  Some  of  the  rationale  for  physically  implementing  composite  elements  lie  in 
tradeoffs  that  sometimes  emerge  for  storage  efficiency,  disk  VO  efficiency,  and  alignment 
with  what  has  already  been  defined  in  existing  systems.  A  comparison  of  two  data  storage 
structures,  shown  in  Figure  2-5,  illustrates  how  some  of  these  tradeoffs  work  using  the 
example  of  coupled  data  elements  discussed  earlier.  Using  a  data  structure  assembled 
from  the  coupled  data  elements  (part  a),  a  single  input  operation  can  access  all  six  strength 
authorizations.  The  record  (without  indexes)  requires  a  total  of  18  bytes  of  storage.  The 
same  data  in  a  data  structure  assembled  from  the  uncoupled  data  elements  requires  six  input 
operations  to  retrieve  the  same  data,  and  the  record  structure  (without  indexes)  requires  a 
total  of  78  bytes  of  storage. 

7.  Modularity  and  maintainability  promoted  by  single  concept  formulations 
minimize  changes  that  would  be  required  to  split  authorized  enlisted  strength  into 
authorized  senior  enlisted  strength  and  authorized  junior  enlisted  strength.  Notice  that  the 
record  layout  must  change  for  tire  structure  using  coupled  data  elements,  but  stands 
unchanged  for  the  structure  using  single-concept  elements.  For  tire  structure  using  coupled 
elements,  tire  Authorized  Enlisted  Strength  element  would  be  dropped,  and  two  new 
elements  -  Authorized  Senior  Enlisted  Strength  and  Authorized  Junior  Enlisted  Strength  - 
would  be  added.  For  the  structure  using  single-concept  elements  the  current  resource  code 
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Coupled  Strength  Data  Elements:  A  single  input  operation  can  access  all  six  authorizations 

The  amount  of  storage  used  is  6+  (6  x  2)  *  18. 


Key 

Authorized 

Officer 

Strength 

Authorized 

Warrant 

Officer 

Strength 

Authorized 

Enlisted 

Strength 

Authorized 
Civilian  UJ5. 
Direct  Hire 
Strength 

Authorized 

Civilian 

Foreign 

National 

Strength 

Authorized 

Civilian 

Indirect 

Hire 

WEAFAA 

'  7 

1 

37 

12 

0 

0 

Uncoupled  Strength  Data  Elements:  Multiple  input  operations  needed  to  access  all  authorizations. 

The  amount  of  storage  used  is  13  x  6  »  78 


Key 

Strength 

Type 

Code 

Resource 

Code 

Strength 

Quantity 

WEAFAA 

A 

AAOF 

7 

WEAFAA 

A 

AAWO 

1 

WEAFAA 

A 

AAEN 

37 

WEAFAA 

A 

CUDH 

12 

WEAFAA 

A 

CFDH 

0 

WEAFAA 

A 

CFIH 

0 

Resource  Code  Values 


AAOF 

Officer 

AAWO 

Warrant  Officer 

AAEN 

Enlisted 

CUDH 

Civilian  U.S.  Direct  Hire 

CFDH 

Civilian  Foreign  National 

CFIH 

Civilian  Indirect  Hire 

Strength  Type  Code  Values 

A  Authorized 

S  Structured 


Figure  2-5  Illustration  of  the  Influence  Coupling  vs.  Cohesion 
Alternatives  Can  Have  on  Storage  and  Performance 
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for  Enlisted  would  be  dropped  and  two  new  codes  for  Senior  Enlisted  and  Junior  Enlisted 
would  be  added. 

8 .  Implementation  tradeoffs  must  be  evaluated  to  properly  decide  whether  data 
elements  will  be  formulated  as  couplings.  This  must  not,  however,  become  an  excuse  for 
not  formulating  the  single  concept  element  A  logical  database  design  should  always  fully 
normalize  die  data  and  formulate  the  data  elements  as  single-concept  elements.  Just  as  data 
structures  must  sometimes  deviate  from  rules  of  full  normalization  for  die  physical  database 
design  to  accommodate  an  application's  storage  requirements  or  data  access/update 
performance,  physical  data  element  designs  must  sometimes  deviate  from  the  single 
concept  formulation.  But  these  implementation  decisions  should  be  made  based  on  a  full 
understanding  of  how  data  arc  lo  "ally  >  ~*ated. 

9.  Adhering  to  single-concept  elements  in  the  logical  database  design  and 
allowing  multi-concept  elements  in  the  physical  database  design  creates  a  requirement  to 
map  the  logical  database  design  to  the  physical  database  design  at  both  an  entity/recard  level 
and  a  data  element  level.  The  logical  database  should  be  consulted  whenever  alternative 
approaches  are  being  evaluated  for  upgrading  die  database  design.  Evaluating  upgrade 
alternatives  against  the  logical  model  ensures  that  impacts  are  weighed  against  the  full  set  of 
data  relationships.  An  evaluation  of  upgrade  alternatives  against  die  physical  database 
design  is  likely  to  miss  relationships  diminished  or  hidden  by  steps  taken  to  denonnalize 
die  data  and  bundle  multiple  concepts  within  single  data  elements. 

E-  MULTI-PURPOSE  DATA  ELEMENTS 

1.  A  multi-purpose  data  element  is  a  single  storage  space  that  is  used  to  store 
data  values  describing  a  variety  of  different  concepts.  Although  die  storage  area  is  nanwd 
and  managed  as  a  single  data  element,  it  is  doing  die  job  of  several  data  clgm«itK 
Typically  die  analyst  formulating  die  multi-purpose  element  takes  advantage  of  a  mutual 
exclusivity  that  often  exists  for  the  attributes  collected  on  different  entity  subtypes.  There 
are,  for  example,  different  types  of  people  in  die  Army  -  Military  Officers,  Military 
Enlisted,  Civilians,  etc.  These  are  different  subtypes  for  die  ‘personnel’  entity.  Some 
attributes  are  shared  by  all  three  subtypes  (e.g..  Name,  Social  Security  Number,  Birth 
Date,  etc.),  but  there  are  other  attributes  that  only  apply  to  die  different  types  (e.g..  Area  of 
Concentration  (AOC)  for  Military  Officers,  Military  Occupation  Specialty  (MOS)  for 
Enlisted,  and  Occupational  Code  for  Civilians).  Elements  that  apply  only  to  the  different 
subtypes  of  die  entity  become  candidates  far  multi-purpose  formulations.  The  context  of 
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the  multi-purpose  data  element's  value  change  based  on  what  type  of  entity  is  described  by 
a  specific  record. 

2.  Data  elements  formulated  for  multiple  uses  are  difficult  to  interpret  because 
die  meaning  of  their  values  depends  on  the  context  in  which  the  data  values  appear.  Figure 
2-6  shows  an  example  of  a  multi-purpose  data  element  The  existence  of  a  multi-purpose 
data  element  can  often  be  detected  by  the  different  categories  of  allowable  values  that  appear 
in  domain  value  lists  for  the  data  element  Over  time,  as  new  data  requirements  are 
continuously  introduced,  and  as  business  rules  mature,  die  protocol  for  determining  the 
context  far  die  values  for  a  multi-purpose  element  tends  to  collapse;  it  becomes  possible 
that  the  element  could  have  two  legitimate  values. 

3 .  Multi-purpose  elements  are  sometimes  used  to  accommodate  varying 
formulations  for  an  element  by  different  systems  and/or  organizations.  Different 
organizations  may  have  assembled  varying  legacy  elements  that,  from  a  global  integration' 
perspective,  should  be  treated  as  having  identical  meaning.  This  case  is  illustrated  for 
technical  manual  (TM)  numbers  in  Figure  2-7.  Technical  manual  numbers  are  formatted 
differently  across  the  Army,  Navy,  and  Air  Force.  Under  current  standards  (MIL-STD- 
1388-2B)  on  the  transmittal  and  delivery  of  automated  Logistics  Support  Analysis  Records 
(LSAR)  die  technical  manual  number  is  transmitted  as  a  composite  data  item.  Technical 
manual  number  is  made  up  of  many  elements  having  different  embedded  meaning  from 
both  a  semantic  and  syntactical  points  of  view  across  die  Army,  Navy,  and  Air  Force. 
Nevertheless,  in  die  exchange  format,  the  TM  number  is  treated  as  a  angle  information 
concept  with  identical  meaning.  This  single  information  concept  transmittal  is  «lsr> 
followed  under  die  DoD  standards  (e.g.,  MEL-STD-1840). 
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Principle 


Definition/Use 

A 


Definition/Use 

B 


Example 

UNPID  Unit  Package  Identifier 

1.  Force  Grouping  •  when  component  code(COMPO)  =  1 

Code  Description 

AA  •  HQ  USAREUR  7A 
AB  -HQ  Staff  Act  (200  MMQ 
SO  -  HQ  V  Corps/ Associated  Units 


lv/rtVW.VW.VA%V.V//AW/Aviv>iVAV.V 


Data  Element  with  Integrity 


1 


Singular  Definition 
and  Use  J 


2.  HNS  and  LOG  Civil  Augmentation  Program  Offset 
Accumulation  Indicator  -when  COMPO  *  4,7,8,  or  9) 

Code  Description 

SH  Recognized  Unit  Shortfall 

HD  HNS  Direct  Offset 

HI  HNS  Indirect  Offset 

CC  LOG  Civil  Augmentation  Program  Offset 


Figure  2-6  Multi-Purpose  Storage  Space 


Army  Technical  Manual  (TM)  Number  TM  5-5420-2 1 0-20P-2» 

TM  Indicates  this  Publication  is  a  Technical  Manual  \ 

5-  Series  Number  (Engineers)  ' 

5420-  Federal  Supply  Class  for  Equipment  (Bridges) 

210-  Sequence  Number 
20P-  Indicates  TMS  is  RPST1  for  unit  maintenance 
2  Second  Volume 

Navy  Technical  Manual  (TM)  Number  AE- 1 72 A0-720- 1 00  — 

A  Indicates  Publication  is  NATSF  Controlled  NAVAIR  TM 

E-172  Shows  th&tTM  is  for  Ekctronic  Navigation  Equipment 

AO-  Serial  Number  designating  Stewart  Warner  Models  i 

720-  Work  Unit  Code  for  Radar  Navigation  Systems  / 

10  Indicates  Volume  Number  in  Set  / 

0  Change/Revision  Number  / 

Air  Force  Technical  Order  (TO)  Number  12R5-2ARN24-2 

12  Indicates  Publication  is  for  Airborne  Ekctronic  Equipment 

R  Shows  that  TM  is  for  Radio  System 

5  Equipment  Series  for  Navigational  Equipment 

2  Indicates  that  JETDS  Nomenclature  Applies 
ARN  JETDS  Nomenclature:  A  «  Airborne,  R  *  Radio,  N  «  Navigator 
24  Model  Number 

2  Indicates  TO  to  be  a  Maintenance  Manual 


Figure  2-7  Different  Chain  Syntax  Exchanged  as  Single  Composite  Semantic 


•MEL-STD-1388-2B 
Technical  Manual  Number. 

Th^.  Iwhnifll  mmtl 

technical  order,  or  manual 

mntmllnig  mimhw  mjgmj 

by  the  requiring  authority. 

Held  Length:  20 
Type:  AN 

Justification:  Left 
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F.  SYNERGISM  BETWEEN  DATA  MODELING  AND  DATA 
FORMULATION 


aiajiaji 


1 .  Advantages  and  disadvantages  presented  above  for  chained,  coupled,  and  multi¬ 
purpose  composite  element  formulations  elevate  data  element  mapping  as  a  management  tool  for 
rinnim^nting  and  ridding  how  a  specific  element  should  be  implemented.  A  dear  distinction  can 
be  madft  between  formulation  practices  for  communicating  data  requirements,  and  formulation 
practices  for  supporting  physical  datahao*  implementation. 


a.  A  logical  data  element  (Le.,  attribute)  is  the  smallest  concept  that  is 
nam^d  and  modeled  (Le.,  it  cannot  be  decomposed  without  loss  of  meaning).  Logical  data 
elements  must  communicate  data  requirements.  Data  elements  formulated  to  describe  a 
single  concept  communicate  data  requirements  well  because  they  are  modular  and  mutually 
exclusive  in  their  definition. 


b.  Physical  data  elements  must  carry  data  and  support  implementation 

related  requirements  for  storage,  performance  (retrieval  and  update),  and  information 
exchange.  These  requirements  sometimes  can  best  be  met  by  designing  composite 
elements. 


c.  When  composites  are  designed,  they  spawn  associations  due  to 
partially  overlapping  definitions  that  hide  information  important  for  managing  integration 
and  redundancy.  If  not  managed  properly,  composites  can  hinder  communication  and 
coordination  across  die  department  To  mitigate  against  these  disadvantages,  data  element 
associations  created  by  composite  elements  need  to  be  documented  so  they  can  be  quickly 
detected  during  downstream  data  element  research. 

2.  Composite  elements  should  be  decomposed  early  in  die  data  modeling  projects 

because  they  often  reveal  important  information  or  hnamgas  rules  far  supporting  the  wMvteliwg 

effort  Figures  2-8  and  2-9  illustrate  this  point  by  example  -  a  legacy  dement  named  Troop 
Program  Sequence  Number  (TPSN).  This  element  is  a  composite  of  approximately  nine  concepts. 
When  elements  like  TPSN  are  modeled  as  shown  in  Figure  2-8,  no  consideration  is  given  for 
discovering  and  communicating  the  concepts  and  business  rules  hidden  within  their  formulation. 
The  model  shown  in  Figure  2-9  reveals  data  requirements  and  subtyping  ofMTOE  Units  that  could 
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Unit/1 


Unit  Identification  Code 


Unit  Type  Code 


MTOE  Unit  Subset/3 


Unit  Identification  Code 
Effective  Date 


Standard  Requirements  Code 


Unit  Subset/2 


Unit  Identification  Code 
Effective  Date 


Troop  Program  Sequence  Number 
•  •  • 

(S  C/aft  Type  Code 

- — ' '  ‘~1 

TDA  Unit  Subset/4 

Unit  Identification  Code 
Effective  Date 

Report  Code 


Composite 

Formulation 


Figure  2-8  ERD  with  Composite  Troop  Program  Sequence  Number 


Unit/l 


Unit  Subset/2 


Deeompos 
Formulation 


MTOE  Divisional  Unit  Subset/S 


Unit  identification  Code 
Effective  Dace 


MTOE  Noo-Di visional  Unit  Subset/6 


Unit  Uentifigiion  Code 
Effective  Date 


Master  Unit  Type  Code  (TPSN  pen  2)  Non-Mastm  Unit  Type  Code  (TPSN  pen  2-3)  *4 

Special  Class  Number  (TPSN  pen  3)  Requireiacnts  Docammt  Seqaeace  Number  (TPSN  pen 
Master  UnttNnmlMr  (TPSN  nan  4-«aH 


Figure  2-9  ERD  with  DecomposedTroop  Program  Sequence  Number 
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not  be  communicated  without  reading  die  regulation  (reference  (h))  developed  to  help  users  enter 
values  into  the  TPSN. 

G.  COMPOSITE  EI JEMFNT  STANDARDIZATION  GUIDELINES 

1 .  Practices  used  to  design  composite  data  elements  generally  lower  die  element’s 
familiarity  to  the  users,  restrict  die  element’s  usage  to  the  application  for  which  it  is  designed,  and 
increase  die  probability  that  the  element  will  regularly  need  to  be  changed.  Furthermore,  composite 
element  definitions  partially  overlap  with  definitions  of  other  data  elements  used  throughout  die 
Department  This  redundancy  sets  the  stage  for  data  inconsistencies,  increases  system  maintenance 
costs,  and  reduces  system  flexibility  for  accommodating  new  data  requirements. 

2.  If  managed  as  a  technique  for  reconciling  low  risk  exceptions  to  data 
standardization  rules,  practices  used  to  design  composite  data  elements  can  effectively  address 
external  data  exchange  requirements,  satisfy  performance  issues,  and  expedite  d*t»  integration. 

3.  A  practical  approach  must  be  taken  when  deciding  how  to  reconcile  composite  data 
elements.  Many  chained  elements  are  institutionalized  and  well  understood  by  die  functional 
community.  For  institutionalized  composite  elements,  a  decision  to  standardize  should  consider 
options  to  partially  decompose  the  element  Tire  objective  is  to  improve  data  sharing  with  full 
consideration  of  tire  costs  and  benefits  in  terms  of  specific  obstacles  tire  dement  presents  to  data 
sharing  versus  data  exchange.  Consider  options  for  partial  decomposition  nf  institutional! 
composite  elements  when: 

a.  The  element  is  thoroughly  institutionalized  and  well  accepted  as  a  standard 
approach  for  accessing  and  exchanging  data. 

b.  Concepts  embedded  in  the  composite  element  do  not  appear  to  have 
potential  use  across  functional  areas. 

c.  The  element  has  shown  no  instability  in  tire  past  (e.g.,  no  projects  have 
been  initiated  to  re-design  tire  coding  structure). 

d.  Chained  concepts  appear  to  represent  a  naming  discipline  that  does  not 
extend  beyond  tire  scope  of  tire  object  described  by  tire  data  element 
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4 .  Coordination  and  communication  about  die  composite  data  element  can  be  improved 

by  mapping  its  formulation  to  a  set  of  single  concept  equivalent  formulations.  Mapping  is  essential 
whether  die  composite  data  element  is  standardized  as  a  single  concept  or  composite  concept 
formulation.  Mapping  improves: 

a.  Database  Migration.  Recognizing  that  composite  elements  abound  in 
existing  DoD  systems  and  data  exchange  transactions,  DoD  data  standardization  procedures  and 
tools  must  accommodate  and  manage  migration  of  composite  elements  to  single  concept  elements. 
When  a  composite  element  is  fully  documented,  database  re-engineering  can  accelerate  because  die 
data  requirements  are  already  decomposed  into  equivalent  sets  of  single  concept  formulations. 
Additionally,  the  composite  element  relates  more  easily  to  data  outside  the  system  (e.g.,  external 
standards). 


b.  System  Usability.  Mapping  documentation  helps  new  system  users 
understand  composite  elements,  and  provides  a  basis  for  improving  labels  used  in  system 
interfaces. 

c.  Data  Sharing.  Mapping  documentation  improves  coordination  and 
communication  for  any  aspect  of  data  sharing.  Although  difficult  and  time-consuming,  proper 
analysis  for  documenting  composite  elements  prevents  repetitive  analysis  in  the  fixture. 

J.  MODEL  FOR  DOrt  JMFNTTNTi  COMPOSITE  FT  EMENT  FORMULATIONS 

1.  Perspective. 

The  model  presented  below  will  help  capture  and  coordinate  information  about  how 
composite  data  element  formulations  decompose  or  map  into  equivalent  single  concept 
formulations. 

2.  Semantic  Rules. 

Any  approach  used  to  map  a  composite  element  to  a  set  of  equivalent  angix  concept 
formulations  must  account  for  three  requirements: 

a.  A  many-to-many  relationship  exists  *  Turing  composite  and 

equivalent  single  concept  elements. 
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b.  A  composite  element  can  hierarchically  decompose  through  an  arbitrary 
number  of  levels  to  a  set  of  equivalent  single  concept  elements. 

c.  Different  types  of  associations  (e.g.,  chain,  coupling,  multi-purpose)  exist 
among  die  elements  in  a  hierarchical  decomposition.  Each  type  is  characterized  by  attributes  (e.g., 
element  'A'  PARTICIPATES  IN  'position  x'  of  chain  rB',  where  position  x  is  the  value  of  an 
attribute  for  the  association  between  element  'A'  and  chain  *B'.). 

3.  Relational  Model  Overview 

A  relational  model  in  Figure  2-10  supports  semantics  described  above  using  seven 
entities.  The  data  element  entity  is  already  provided  for  in  the  DDRS.  The  remaining  tables  can  be 
added  in  pairs  to  provide  for  increasing  levels  of  functionality  in  documenting  and  managing  data 
element  associations: 


a.  Document  Data  Element  Associations.  The  Association  entity  and 
Association  Member  entity  together  provide  the  information  needed  to  document  data  element 
associations  for  all  three  types  of  composite  dements  discussed  (Le.,  chain,  coupling,  and  multi¬ 
purpose). 


b.  Document  Attributes  for  the  Data  Element  Associations  The  Association 
Attribute  Value  entity  and  die  Association  Member  Attribute  Value  entity  provide  information  for 
describing  specifically  how  a  composite  element  decomposes  into  its  constituent  simpler  pieces 

c.  Define  New  Types  of  Associations.  The  Association  Type  entity  and 
Association  Attribute  entity  provide  information  for  defining  new  types  of  associations  For 
example,  an  association  could  be  defined  for  tracking  elements  that  when  vfcwed  individually  cany 
unclassified  information,  but  when  viewed  as  a  group  communicate  rfatrififri  information. 
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Association  Type  Association  Attribute 


Figure  2-10  Logical  Data  Model  for  Documenting  Composite  Formulations 
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4.  Entity  Descriptions 


a.  Association  Type.  Lists  all  types  of  associations  (e.g.,  Chain,  Couple,  and 
Multi-purpose). 

b.  Association  Attribute.  Defines  attributes  for  documenting  each  association 
type.  Metadata  attributes  below  represent  example  attributes  far  the  three  different  types  of 
associations  discussed  so  far 

(1)  Couple.  Values  of  composite  elements  correlated  to  counterpart 
values  of  their  single  concept  equivalents. 

(2)  Chain.  The  specific  position(s)  each  secondary  element  occupies  in 
the  domain  values  for  the  composite  element 

(3)  Multi-purpose.  Values  of  die  elements)  used  to  determine  the 
different  uses  of  a  composite  element 

c.  Data  Element  Specifies  all  data  elements,  composite  and  single  concept 

d.  Association.  Identifies  and  describes  each  instance  of  an  association 
among  data  elements  participating  in  a  composite  formulation. 

e.  Association  Member.  Lists  data  elements  participating  in  each  of  the 
associations  recorded  in  die  Association  entity,  and  indicates  the  role  Ccomposite  whole'  versus 
'composite  parf)  each  element  serves.  For  each  of  the  association  types  discussed  earlier  (ix., 
chain,  couple,  and  multipurpose),  an  element  can  serve  in  one  of  two  roles: 

(1)  Primary  Element  Represents  the  'composite  whole.'  The  element 
bundles  into  itself  all  concepts  earned  by  each  of  die  other  elements  in  the  association.  For 
example.  Four  Passenger  Automobile  Count  is  a  primary  element  that  bundles  into  itself  the 
concepts  carried  by  Automobile  Count,  Automobile  Type  Code,  and  Automobile  Seating  Capacity 
Count 


(2)  Secondary  Element.  Represents  the 'composite  part '  The  element 
participates  in  die  association  by  carrying  a  subset  of  the  coocepts  bundled  by  the  primary  element. 
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A  secondary  element  represents  a  lower  level  of  concept  bundling  than  the  primary  element  The 
elements  Automobile  Count,  Automobile  Type  Code,  and  Automobile  Seating  Capacity  Count  are 
each  secondary  elements  associated  with  Four  Passenger  Automobile  Count 

f.  Association  Attribute  Value.  Records  the  values  for  the  association 
attributes  identified  in  die  Association  Attribute  entity  at  the  association  level 


g.  Association  Member  Attribute  Value.  Records  the  values  for  the  association 
attributes  identified  in  Association  Attribute  entity  at  die  association  member  level  As  described 
above  for  die  Association  Attribute  entity,  attributes  appropriate  for  describing  an  association  vary 
for  different  types  of  element  associations.  For  example,  this  entity  could  capture  the  actual  value 
of  an  attribute  named  'Chain  Column'  for  elements  participating  in  a  'Chain'  type  assnriayinn 


K.  EXAMPLE  COMPOSITE  ELEMENT  FORMULATION 


1 .  Introduction.  This  section  describes  an  example  composite  element  called  the  Unit 
Requirements  Objective  Code  (ROBCO)  summarized  in  Figure  2-11.  This  example  is  nwi  to 
illustrate  how  die  logical  model  described  in  Section  E  can  be  used  to  document  die  Avywnpftdtinw 
of  composite  elements  into  equivalent  single  concept  formulations. 

2.  Chain  Formulation  (Level  ll  ROBCO  is  a  four  position  data  element  chain.  The 
primary  and  secondary  elements  in  the  chain  association  are: 


Primary  Element 
Unit  Requirements 
Objective  Code 


Scoadag 
Arrival  Time  Period 
Theater  Employment  Code 
Functional  Role  Code 
POMCUSCode 


(Position  1) 
(Position  2) 
(Position  3) 
(Position  4) 


Each  position  of  the  composite  chain  further  decomposes  into  a  second  layer  of  associations.  For 
this  example,  the  first  and  fourth  positions  (Le.,  Arrival  lime  Period,  and  POMCUS  Code)  are 
further  decomposed  below. 
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figure  2-11  Example  Decomposition  of  a  Composite  Element  to 
Equivalent  Single  Concept  Elements 
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4. 


Couple  Formulation  (Level  2.  Pi 


•XMHUI 


1  -  Arrival  Time  Period) 


a.  The  Arrival  Time  Period  is  formulated  as  a  coupling  of  dime  concepts; 

Primary  Element  Secondary  Elements 

Arrival  Time  Period  Requirement  Readiness  Alert  Code 

Unit  Requirement  Latest  Arrival  Period 
Unit  Requirement  Deployment  Code 

b.  The  secondary  elements  are  bundled  into  die  first  position  by  assigning 
different  coded  values  for  each  allowable  combination  of  the  three  different  concepts  they  describe. 
There  are,  for  example,  three  different  values  for  'C+5  TO  C+15':  1)  die  value  *B'  indicates  that  a 
unit  supports  Combat  requirements;  2)  the  value  <C  indicates  that  a  unit  supports  CS/CSS 
(Combat  Support/Combat  Service  Support)  requirements;  and  3)  die  value  *2’  indicates  that  a  unit 
supports  Non-RDF  (Rapid  Deployment  Force)  requirements.  Names  for  the  secondary  elements 
have  been  synthesized  from  the  coded  values  as  follows: 

(1)  Requirement  Readiness  Alert  Code  describes  whether  the  unit  is  to 
arrive  on  station  when  mobilization  begins  (Le.,  M'-Day),  deployment  begins  (Le.,  D'-Day),  or 
commencement  of  hostilities  (i.e.,  C-Day). 

(2)  Unit  Requirement  Latest  Arrival  Period  describes  the  earliest  and 
latest  number  of  days  in  which  die  unit  is  to  arrive  on  station  after  die  start  of  Latest  Arrival  Period 
(e.g.,  0-4,  5-15,  16-30). 

(3)  Unit  Requirement  Deployment  Code  describes  whether  the  unit  is 
serving  in  a  category  of  Combat,  Combat  Support  (CS),  Combat  Service  Support  (CS/CSS), 
and/or  Non  RDF  (Rapid  Deployment  Force). 

5.  Multi-Puroose  Formulation  (Level  2.  Position  4  -  POMCUS  Codcl 

a.  The  POMCUS  Code  (representing  the  Prepositioning  of  Materiel 
Configured  to  Unit  Sets)  is  formulated  as  a  multipurpose  element  for  two  concepts: 

Primary  Element  Secondary  Element* 

POMCUS  Code  POMCUS  Division-Set  Code 

Unit  Deployment  Assignment  Code 

b.  The  names  for  the  secondary  elements  have  been  synthesized  from  the 
coded  values  as  follows: 
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(1)  POMCUS  Division-Set  Code  identifies  the  number  for  a  POMCUS 
Division-Set  (e.g.,  T  for  Division-Set  1,  *2'  for  Division  Set-2,  etc.)  and  the  Division  Set 
Category  (e.g.,  units  or  PBF).  Hie  POMCUS  Division  Set  Code  applies  to  documentation  for 
units  that  have  a  Force  Component  Code  equal  ("=")  to  9. 


(2)  Unit  Deployment  Assignment  Code  describes  die  force  grouping  a 
unit  supports  as  part  of  a  specific  contingency  plan  assignment  It  applies  to  Non-POMCUS  units 
(ix.,  Force  Component  Code  not  equal  C\=")  to  9). 


5. 


Couple  Formulation  (Level  3.  Position  4  - 


JS.PiYiaQn-Sct  Code) 


Two  concepts  arc  coupled  into  die  POMCUS  Division-Set  Code  by  assigning 
different  coded  values  for  each  allowable  combination  of  a  POMCUS  Set  Number,  and  a 
POMCUS  Set  Category.  There  arc,  for  example,  two  different  values  for  Division  Set  1':  l)the 
value '  1 '  indicates  that  the  record  describes  a  unit;  2)  the  value  'A'  indicates  that  record  describes  a 
PBF. 


L. 


rAHON  FOR  THE  EXAMPLE  C( 


E  FORMULATION 


1.  Figure  2-12  displays  the  documentation  for  concepts  bundled  into  the  ROBCO 
formulations  described  above  using  die  model  proposed  in  Section  E. 

2.  One  record  exists  in  die  data  element  entity  for  each  of  the  primary  and  secondary 
elements. 

3.  The  four  associations  discussed  are  documented  in  die  Association  entity. 

4.  The  participation  of  data  elements  in  each  association  is  documented  in  the 
Associate  Member  entity. 

5.  The  hierarchical  decompositiaQ  of  the  composite  element  is  represented  in  the 
Associate  Member  entity  by  the  recurrence  of  a  single  data  element  supporting  different  roles  for 
different  association  instances.  For  example.  Arrival  Time  Period  participaiBS  as  a  secondary 
element  in  association  111' btt  participates  as  a  primary  element  in  association'll?.  likewise 
die  POMCUS  Code  participates  as  a  secondary  element  in  association  '111'  but  participates  as  a 
primary  element  in  association  T 13'.  Hus  unbundling  occurs  again  for  die  element  POMCUS 
Division-Set  Code;  it  participates  as  a  secondary  element  in  association  T 13',  but  participates  as  a 
primary  element  in  association  T14'. 
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6 .  The  Association  Member  Attribute  entity  documents  die  different  attribute  values  for 

each  of  the  different  types  of  associations  based  on  entries  in  the  Association  Attribute  entity.  For 
example: 


a.  'Chain  Column'  attribute  for  chain  type  associations  are  recorded  for  each 
of  die  secondary  elements  participating  in  association  T 1 1'. 

b.  Usage  Context'  for  the  different  uses  of  the  multipurpose  association  are 
documented  for  each  of  die  secondary  elements  participating  in  association  1 13'. 

c.  'Element  Value'  taken  on  by  secondary  elements  when  uncoupled  from 
primary  elements  far  associations  are  documented  for  elements  participating  in  associations  '112' 
and  '114'. 


7.  The  secondary  elements  in  associations  T12'  and  *114’  do  not  appear  as  primary 
elements  in  any  other  associations.  If  die  analysis  for  multiple  concepts  is  complete,  then  these 
elements  are  single  concept  elements.  Because  die  redundancy  will  not  be  masked  by  partially 
overlapping  definitions,  the  single  concept  formulations  can  be  analyzed  for  redundancy  with  other 
single  concept  elements  in  the  dictionary.  Redundancy  is  hard  to  detect  or  verify  across  data 
elements  that  bundle  multiple  concepts  under  a  single  name,  but  can  reasonably  be  detected  when 
disciplines  such  as  naming  conventions  and/or  keyword  associations  are  applied  to  die  single 
concept  elements. 
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CHAPTER  3 

DERIVATIONS 


A.  DEFINTION 

1.  Derived  data  elements  represent  the  results  of  computational  operations  performed 
on  other  data  elements.  The  computations  may  involve  algorithms  joining  two  or  mote  standard 
elements  or  algorithms  summarizing  multiple  occurrences  of  a  single  element 

2.  Computational  associations  among  elements  may  extend  multiple  levels,  creating 
derived  elements  from  other  derived  elements. 

Example: 

Military  Personnel  Allowance  Amount  =  B AQ + BAS 

BAQ  =  Basic  Allowance  for  Quarters  by  Grade 

BAS  =  Basic  Allowance  for  Subsistence 

=  Military  Personnel  End  Strength  by  Grade  *  BAS  Rate 

B.  DERIVATION  STANDARDIZATION  ISSUES 

1.  Case  for  Standarrii^finn  nf  Derivations 

a.  Coordinate  Definitions  of  Common  Derivations.  If  not  documented  and 
agreed  upon,  inconsistently  derived  data  can  easily  lead  to  discrepancy  resolution  projects  to  trace 
down  die  rationale  for  different  answers  to  a  single  question. 

Example: 

How  many  people  work  for  die  Department  of  Defense? 

Different  people  could  come  up  with  very  different  answers  far  this  question  based  cm  whether  the 
data  used  includes  trainees,  contractors,  and/or  unfilled  positions.  Standard  algorithms  for 
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answering  this  type  of  question  provides  coordinating  guidance  to  analysts  and  decision  makers 
working  to  obtain  consistent  results.  These  algorithms  relate  primitive  ‘keyed-in*  data  to  die 
derived  answer. 

b.  Support  for  Policies.  Business  Rules,  and  Lepal  Requirements.  Some 
derived  d^ta  elements  are  used  to  determine  what  processes  are  to  be  performed  or  what  logic  is  to 
be  applied  to  transactions  or  related  data  based  on  business  rules  (e.g.,  Set  the  minimum  and 
maximum  inventory  for  a  specific  repair  part  based  on  die  total  number  of  supported  end  items 
coming  due  for  a  60  thousand  operating  hour  check-up  within  three  months).  Calculated  elements 
in  Figure  3-1  illustrate  a  second  related  rationale  for  representing  derived  elements;  these  elements 
support  accounting  requirements.  Other  derived  elements  may  be  legally  required  (e.g., 
cumulative  annual  employee  pay  amount).  These  types  of  derived  elements  need  to  be  represented 
as  requirements  in  logical  data  models  and  coordinated  to  communicate  policy,  business  rules,  and 
legal  requirements. 


c.  Support  Data  Exchange  Requirements.  Figure  3-2  illustrates  a  data 
exchange  phenomenon  that  is  projected  to  be  quite  common  across  DoD.  Many  decision  support 
(DSS)  systems  extract  and  summarize  snapshots  of  data  from  transaction  systems.  Data  elements 
output  from  the  extract  procedures  are  commonly  documented  as  memoranda  for  agreements 
(MOA)  or  by  standards  that  have  been  established  to  support  data  sharing  (e.g.,  MIL-STD-1388- 
2B;  MIL- STD-1840;  US  Message  Text  Formats).  Although  die  transaction  systems  stone  data  at 
die  primitive  level,  the  DSS  applications  store  the  data  at  an  aggregate  leveL  If  enhancing  data 
shareability  is  the  objective  the  QM  Data  Administration  program,  then  derived  data  need  to  be 
documented  to: 


(1)  Manage  Reuse  of  Data  Exchange  Agreement*  Data  appearing  in 
data  exchange  agreements  can  help  focus  data  administration  efforts  on  data  that  are  widely  shared. 
Statistical  distribution  of  derived  data  appearing  in  these  exchange  agreements  indicate  what 
derived  data  are  of  corporate  interest 

(2)  Communicate  Data  Requirements  for  Decision  Support  Systems. 
Decision  Support  Systems  are  likely  to  deal  directly  with  derived  and  modeling  die  derived 
data  is  appropriate  for  these  types  of  systems. 
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Derived  D«tt  Requirement 


Order  Identifier 


Order  Date 

Order  Discount  Rate 

Order  Discount  Time 

••Total  Diacoumed  Order  Pnee  Amount 

••Total  Undiacooated  Order  Price  Amount 


Order  Order 
Identifier  Date 


A01 
A02 

ao3  I  4/2/93 
A04  4/4/93 


Order 

Order 

Diacount 

Diacount 

Rate 

Time 

10% 

30 

20% 

30 

10% 

60 

5% 

15 

Total 

Discoiiflied 
Order  Pnee 
Amount 

Total 

Older  Price 
Amount 

45.00 

10.00 

927X0 

1121X0 

8888 

S8§8 

Line  Item 


I  iw  Item 

Order  Identifier  (FK) 


Line  Item  Quantity 
Line  Item  Unit  ftioe  Amount 
••Discounted  Order  Price  Amount 
••Undiacotmted  Older  Price  Amount 


Order 

Identifier 

Line  hem 
Identifier 

A01 

001 

A01 

002 

A02 

001 

A03 

001 

A03 

002 

Line  Item 
Unit  Rice 


Derived  Data  Requirement 


Dsaoon*ed 
Order  Pace 


2aoo 

3aoo 

loaoo 

moo 

looaoo 


Figure  3-1  Calculated  Data  Requirements  -  IDEF1X  Model  and  Table  Mockups 
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2.  Case  Against  Sfandarriiy^tinn  nf  Derivation* 

a.  Derived  data  elements  possess  a  number  of  undesirable  characteristics  for 
data  element  standards.  Table  3-1  provides  a  quick  comparison  of  the  traits  for  primitive  and 
derived  data. 


(1)  Primitive  data  represent  observable  facts  of  interest  to  an 

organization.  The  population  of  primitive  data  elements  describing  these  facts  is  finite,  and,  so  long 
as  an  organization's  mission  is  stable,  the  population  of  primitive  data  used  by  die  organization  is 
stable.  primitive  data  element  serves  a  definable  role  that  can  be  represented  in  a  structured 

data  model.  With  the  exception  of  keys  (elements  used  to  uniquely  identify  individual  records),  die 
data  elements  can  be  modeled  as  non-redundant  attributes  in  the  data  model.  These  traits  together 
with  die  common  objective  that  a  single  primitive  data  element  should  be  shared  to  support  a  wide 
range  of  uses  predisposes  primitive  data  for  standardization, 

(2)  Derivative  data  are  generated  as  sums,  ratios,  averages,  or  similar 
transformations  of  primitive  data.  For  practical  management  purposes,  there  are  an  infinite  number 
of  ways  to  select  and  manipulate  combinations  of  primitive  data  to  derive  die  results  used  to 
support  decision  makers.  There  is  also  an  issue  of  derivation  stability  because  they  are  objects 
defined  to  support  the  styles  of  individual  managers.  As  managers  change,  die  procedures  and 
derivation  items  used  to  support  decisions  also  change.  For  this  reason,  derivations  represent  a 
dynamic  and  explosive  population  of  elements  generally  designed  to  support  die  skin  mixes  of 
individual  managers  or  groups  of  managers,  and  not  weU  suited  for  standardization. 

(3)  Derivations  are  by  their  veiy  nature  redundant  with  the  primitive 
elements  from  which  they  are  assimilated.  Furthermore,  the  various  combinations  of  primitive 
elements,  select  criteria,  and  computational  operations  that  can  be  used  to  derive  a  result  guarantee 
that  derivative  data  overlap  with  other  derivative  data  The  matrix  in  Figure  3-3  plots  overlaps 
among  a  set  of  primitive  elements  and  a  set  of  elements  derived  from  those  primitives.  The 
primitive  elements  are  mutually  exclusive  as  a  rule,  but  the  derivations  overlap  as  a  rule. 


« 
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—  Type  of  Data 

Element 

Characteristic  ia_ 

Primitive 

Derivative 

Source  of  Value 

Generated  from  Primitives  (sums,  counts,  averages) 

Number  of  Elements 

Finite 

Infinite 

Definition 

Static 

Dynamic 

Usage 

Structured 

Unstructured 

Widely  Available 

Private 

Mutually  Exclusive 

Overlapping  Definitions 

Examples 

Employee  Grade 
Employee  Step 
Employee  Pay  Rate 

Total  Expended  Employee  Pay  Amount 

Table  3-1  Primitive  Versus  Derived  Data 


Related  Element 

Element 

Derivative  | 

Unit  Identification  Code 

Stock  Item  Shipment  Date 

£ 

i 

1 

1 

i 

I 

►» 

•a 

I 

i 

i 

n 

Stock  Item  Type 

Performance  Timely  Follow-up 
Response  Percentage 

Performance  Total  Records 
Matched 

Additional  Buy-out  Require¬ 
ment 

Additional  Requirement 

Buy-out  in  Subtotal 

Additional  Requirement 

Buy-out  Total 

Primitive 

Unit  IdendficaooD  Code 

;  < 

1 

Stock  Item  Shipment  Date 

1 

Stock  Item  Nomenclature 

im 

1 

Stock  Item  Quantity 

m 

1 

1 

1 

1 

1 

Stock  Item  Type 

1 

1 

■ 

Performance  Timely  Follow-up 

Response  Percental? 

■ 

2 

2 

2 

fHPi 

3 

3 

3 

3 

Performance  Total  Records  Matched 

2 

2 

2 

3 

- 

3 

3 

3 

Additional  Buy-out  Requirement 

2 

2 

3 

3 

Jg| 

3 

3 

Additional  Requirement  Buy-out  in 

■ 

2 

3 

3 

3 

j§§ 

3 

Additional  Requirement  Buy-out  Total 

■ 

2 

3 

3 

3 

3 

AN 

_ Legend _ 

1.  Element  PARTICIPATES  IN  DERIVING  Reined  Element 

2.  Element  DERIVED  FROM  Reined  Element 

3.  Element’s  DERIVATION  OVERLAPS  WITH  DERIVATION  OF  Rela-d  Etemcnt 

Figure  3-3  Relationships  Among  Sample  of  Primitive  and  Derived  Elements 
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(4)  Derived  data  directly  link  to  implementation  issues  concerning 
performance  of  data  retrievals  versus  data  updates,  and  synchroniration  of  redundant  derived  data 
with  the  primitive  data  used  to  fl«itnn1ate  the  result  Derivations  should  not  be  represented  in 
logical  data  models  because  they  bias  die  design  with  a  premature  solution  to  these  issues.  Derived 
Hatfl  should  be  adressed  in  physical  process  modeling. 

b.  The  traits  listed  above  prompt  many  data  administrators  to  avoid  managing 

derivatives  as  standards,  or  even  attempting  to  represent  derivatives  in  corporate  data  models; 
rather,  they  responsibilities  for  derived  data  to  database  administration  and  system 

configuration  management 

3.  Traditional  Versus  Modem  Management  Environment  for  Derivations 

Software  configuration  management  has  traditionally  managed  derivation 
algorithms.  This  worked  when  significant  derivations  required  support  of  software  designers  and 
developers.  Modem  technology  makes  it  possible  to  extract  primitive  data  from  transactional 
source  systems  and  develop  derivatives  with  little  programmer  participation.  Alternative 
approaches  need  to  be  developed  for  coordinating  information  on  derivations  that  are  of  corporate 
interest  One  important  management  consideration  is  to  model  data  to  support  transaction  systems 
separately  from  data  to  support  DSS  applications.  This  encourages  an  early  distinction  between 
uses  of  the  data  in  these  two  very  different  environments. 

C.  DERIVATION  MANAGEMENT  GUIDELINES 

1.  Derivations  in  Data  Models  for  Transaction  Systems.  Evaluate  derivations 
projected  to  be  stored  in  transaction  systems  to  determine  whether  they  support  accounting, 
auditing,  policy,  or  business  rule  enforcement  purposes.  These  elements  are  of  ‘corporate  interest* 
and  should  be  adopted  for  management  as  data  element  standards. 

2.  Data  Summarisation*  for  DSS  Applications.  If  a  computational  result  characterizes 
an  entity  that  represents  a  summarization  or  aggregation  type  object,  evaluate  the  use  of  the  data. 

a.  If  the  data  support  management  type  functions  rather  than  day-to-day 
operations,  they  should  be  treated  as  DSS  application  requirements.  Data  Models  representing 
requirement  for  day-to-day  transactional  operations  will  be  managed  separately  from  data  models 
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representing  requirements  for  managerial  DSS  applications.  An  element  appearing  in  DSS  data 
models  will  be  of  corporate  interest  and  standardized  if  it  satisfies  one  of  the  following  criteria: 

(1)  Supports  a  Formalized  Process.  A  derived  element  is  computed  in 
support  of  an  officially  documented  process  based  on  inputs  from  multiple  functional  areas. 

(2)  Used  Bv  Multiple  Functional  Areas.  Once  derived,  the  result  is 
shared  with  at  least  five  organizations  in  different  functional  areas. 

(3)  Shared  with  External  OrganiTationrsV  Once  derived,  the  result  is 
shared  with  at  least  one  external  organization. 

b.  Data  elements  that  appear  to  be  derivatives  must  be  closely  investigated 
before  relegating  them  to  DSS  application  models.  Some  counts  and  totals  which  appear  to  be 
derivatives  may,  in  fact,  have  no  primitive  source  for  their  computation.  Figure  3-4  lists  some 
examples  appearing  in  the  U.S.  Message  Text  Formats  (USMTF).  For  example,  a  count  on  the 
number  of  displaced  females  over  60  is  developed  by  a  person  or  group  of  persons  actually 
counting  dislocated  woman  over  60  and  reporting  this  number  for  transmittal.  Processing  and 
databases  for  die  operational  environment  used  to  gather  these  data  clearly  must  change  before  this 
data  can  be  documented  and  managed  as  DSS  aggregates.  So  long  as  the  aggregate  must  be 
observed  (Le.,  manually  counted)  and  keyed  for  transmittal,  die  element  should  be  managed  as  a 
primitive. 


3.  Derivation  Mapping  Documentation.  Improve  the  coordination  and  communication 
about  a  standardized  derived  element  by  mapping  it  to  the  primitive  source  elements,  and 
documenting  die  formula  used  to  manipulate  die  primitive  sources  and  obtain  the  result  If  derived 
data  are  to  be  effectively  coordinated,  documentation  specifying  both  which  data  dement* 
participate  in  a  derivation  and  what  operations  are  performed  against  the  data  elements  must  be 
captured. 
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US-CIVILIAN  PERSONNEL  QUANTITY:  The  non-monetary  unit  representing  the  count  of 
American  non-military  persons  in  the  area  of  operations 

COMMAND  AUTHORIZED  MILITARY  PERSONNEL  QUANTITY :  The  non-monetary  unit 
representing  the  count  of  persons  employed  by  die  Armed  Forces  who  are  approved  to  serve 
within  an  organization  of  units  under  the  authority  of  (me  individual. 

DISLOCATED  FEMALE  CIVILIAN  PERSONNEL  OVER-60- YEARS  QUANTITY:  The  non¬ 
monetary  unit  representing  the  count  of  non-military,  female  persons  over  the  age  of  60  who  are 
displaced  from  their  normal  locations. 

INTERNED  ENEMY  CIVILIAN  PERSONNEL  QUANTITY:  The  non-monetary  unit 
representing  the  count  of  non-combatant,  hostile  prisoners. 

TOTAL  FUEL  REQUIRED  HUNDREDS-OF-POUNDS  WEIGHT:  The  mass  of  total  propellent 
times  die  acceleration  of  gravity,  expressed  in  hundreds  of  pounds,  that  a  tanker  aircraft  needs  to 
transfer  to  receiving  aircraft 

ESTIMATED  MILITARY  PERSONNEL  KILLED-IN- ACTION  QUANTIT  Y:  The  non-monetary 
unit  representing  tire  approximate  count  of  persons  employed  by  the  Armed  Farces  who  die  of 
wounds  received  in  combat  before  reaching  a  medical  treatment  facility 

Figure  3-4  U.S.  Message  Text  Formats  -  Counts  Recorded 

4.  Derivation  Software  Reuse.  Develop  modularized  code  for  calculating  derived  data 

that  satisfies  the  criteria  for  reusable  software.  This  code  win  improve  die  reuse  of  algorithms  used 
to  manipulate  primitive  data.  Register  thes^  modules  in  the  software  reuse  library,  and  record  the 
name  of  die  reusable  software  module  as  an  attribute  of  the  derived  data  element 

D.  MODEL  FOR  DOCUMENTING  DERIVATIONS 

1-  Perspective.  The  model  in  Bgm  3-5  builds  upon  the  model  presented  earlier  for 
documenting  a  composite  element's  formulation,  From  this  perspective  a  derivation  is  an 
algorithmic  association  among  two  or  more  data  elements. 
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2.  Semantic  Rules 

A  derivation  model  must  account  for  die  following  inherent  characteristics  of  a 

derivation: 


a.  A  many-to-many  relationship  exists  between  derived  elements  and  the 
primitive  elements  participating  in  the  algorithms  used  to  generate  the  derived  elements. 

b.  A  derived  element  can  hierarchically  decompose  through  multiple  levels  to  a 
set  of  primitive  source  elements. 

c.  Attributes,  such  as  the  'derivation  algorithm  text',  and  'reusable  software 
module  identifier*  that  characterize  the  derivation  need  to  be  captured. 


3.  Relational  Model  Overview 

The  model  presented  earlier.  Figure  2-10,  is  adapted  far  documenting  derived  data 
in  Figure  3-5.  The  data  element  entity  is  already  provided  for  in  die  DDRS.  The  remaining  tables 
can  be  added  in  groups  of  two  or  three  to  provide  for  increasing  levels  of  functionality  in 
documenting  and  managing  derivations: 

a.  DocumcnLData  Elements  Participating  in  Derivations  The  Association 
entity  and  Association  Member  entity  together  provide  die  information  needed  to  document  what 
data  elements  participate  in  a  derivation. 

b.  Document  Attributes  for  the  Derivation.  The  Association  Attribute  Value 
entity.  Association  Member  Attribute  Value  entity,  and  die  Domain  Constraint  Description  Text 
entity  provide  information  for  describing  a  calculation. 


C.  Define  New  Types  of  Associations.  The  Association  Type  entity  and 
Association  Attribute  entity  provide  information  for  defining  new  types  of  associations. 


4.  Entity  Descriptions.  The  model  comprises  the  following  eight  entities: 


a.  Association  Type.  Defines  'derivation' as  a  type  of  association. 
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b.  Association  Rule.  Defines  attributes  for  documenting  derivations  (e.g., 
'derivation  algorithm  text',  and  'reusable  software  module  identifier’). 

c.  Data  Element  Defines  primitive  and  derived  data  elements. 


d.  Association.  Identifies  and  describes  each  instance  of  an  association  among 
data  elements  participating  in  an  algorithm  to  generate  derived  data. 


e.  Association  Member.  Identifies  the  data  elements  participating  in  each 
derivation  and  die  association  role  each  element  serves.  An  element  can  serve  in  one  of  two  redes: 

(1)  Primary  Element.  Represents  the ’result'  For  example.  Employee 
Age  is  die  result  of  die  computational  difference  between  today's  date  and  die  Employee  Birth 
Date. 


(2)  Secondary  Element  Represents  a 'computational  variable'  used  to 

compute  die  result 


f.  Association  Attribute  Value.  Records  values  for  derivation  attributes 
identified  in  the  Association  Attribute  entity  at  die  association  level  (e.g.,  values  for  'derivation 
algorithm  text',  and  'reusable  software  module  identifier*). 

g.  Association  Manta  Attribute  Value.  Records  values  for  derivation 
attributes  identified  in  the  Association  Attribute  entity  at  the  member  level  (e.g^  a  short 'argument 
name'  might  be  Hcfirwt  for  each  data  element  to  maw  the  w^hww«ii«ii  relationships  among 
elements  appearing  in  the  'derivation  algorithm  text*  easier  to  observe). 
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Figure  3-5  Logical  Data  Model  for  Documenting  Derivation  Associations 


I 

I 

I 

I 
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h.  Domain  Constraint  Description  Text.  Specifies  any  constraints  in  effect  for 
selecting  or  using  data  to  generate  the  derived  data  (e.g.,  enumerated  values,  ranges,  or  SQL 
'where-clause'  text). 


6. 


Possible  E 


Formulas  could  be  treated  more  rigorously  by  modeling  a  standard  list  of  operators 
(e.g„  addition  ('+’),  multiplication  ('*0.  and  square  root  ('SQRTO').  Given  die  objective  of 
simply  improving  communication  rather  than  actually  automating  die  generation  of  program  code  to 
perform  the  computations,  this  additional  level  of  complexity  was  dropped  from  the  model 


E.  EXAMPLE  DERIVATION 

1.  Figure  3-6  presents  an  example  of  a  derived  data  element  called  Military  Personnel 

Pay  Amount: 


Primary  Element 

Military  Personnel  Pay  Amount 


Secondary  Elements 
=  Military  Personnel  Base  Pay 

+  Military  Personnel  Retired  Pay 

+  Military  Personnel  Allowance 

Amount 


2.  Each  of  die  secondary  elements  on  die  right  side  of  the  equation  above  also 

represent  derivations: 


Primary  Element 

Military  Personnel  Base  Pay 


Secondary  Brnimt 

Military  Personnel  End  Strength 
(by  Grade) 

Military  Personnel  Base  Pay 
(for  Grade) 


Military  Personnel  Retired  Pay  *  Military  Personnel  Base  Pay 

*  Military  Personnel  Retired  Pay 

Accrual  Factor  Amount 
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Military  Personnel  Allowance 
Amount 


=  Basic  Allowance  for  Quarters 

+  Basic  Allowance  far  Subsistence 

+  Variable  Housing  Allowance 


3.  Elements  on  the  right  side  of  the 'Military  Personnel  Allowance  Amount’ are 

derived  as: 

Primary  Element  Secondary  Element 

Basic  Allowance  for  Quarters 

(BA Q)  =  [Family  Housing  Requirement 

Family  Housing  Inventory] 

*  BAQRate 


Basic  Allowance  for  Subsistence 

(BAS)  =  Military  Personnel  End  Strength 

(by  Grade) 

*  BAS  Rate 

Variable  Housing  Allowance 

(VHA)  s  [Family  Housing  Requirement 

(by  Location) 

Family  Housing  Inventory 
(by  Location)] 

•  VHA  Rate 

(by  I  ^cation) 

F.  EXAMPLE  DERIVATION  DOCUMENTATION 


1.  Figma  V7  depicts  mUtirmal  model  far  derived 

presented  in  Figure  3-5  can  be  used  to  document  the  primitive  sources  of  tbe  example  derived  data 
element 


3-14 


Figure  3-7  Documentation  of  the  Example  Derived  Element  in  the  Model 
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2.  Derived  Data  Element'  is  identified  as  a  type  of  association  (Le.,  'DRVTN')  in  die 
Association  Type  entity.  The  Association  Attribute  entity  identifies  three  attributes  to  be  recorded 
for  each  instance  of  a  derivation: 

a.  Derivation  Text  (associate  level). 

b.  Reusable  Software  Module  (associate  level). 

c.  Argument  Name  (member  level). 

3.  Each  of  the  data  elements  participating  in  the  derivation  are  documented  in  die  Data 
Element  entity,  and  related  through  the  Association  Member  entity. 

4.  Each  computation  is  identified  in  the  Association  entity,  and  related  to  flrnirntt 
participating  in  die  computation  through  the  Association  Member  entity.  For  example,  the 
derivation  Military  Personnel  Pay  Amount  is  assigned  an  Association  Code  of  ‘SIT.  This  code 
identifies  four  elements  involved  in  the  derivation  within  die  Association  Member  entity  (Le„ 
Military  Personnel  Pay  Amount,  Total  Military  Personnel  Base  Pay,  Military  Personnel  Retired 
Pay,  and  Military  Personnel  Allowance  Amount).  Each  association  includes: 

a.  One  derived  element  (Element  Role  Code  =  7*  for  'Primary  Element1). 

b.  One  or  multiple  computational  variables  (Element  Role  Code  =  *8'  for 
'Secondary  Element*). 

5.  Each  data  element  in  die  Awnriatinn  Member  entity  «  assigned  an  Argument  Name 
in  the  Association  Member  Attribute  Value  entity  (e.g*  the  data  element  Military  Personnel  Pay 
Amount  is  represented  as  MPPA*).  The  argument  name  is  then  used  within  die  derivation  text 
assigned  to  each  association  as  an  'Attribute  Value  Text'  in  the  Association  Attribute  Value  entity. 
Substituting  an  argument  for  the  data  element  nam^  in  the  fonnula  provides  ywy  intelligibility  for 
die  data  elements  being  used,  and,  at  the  same  time,  shortens  die  formula  so  that  mathematical 
relations  among  the  elements  can  more  easily  be  observed.  "Search  and  replace”  logic  could 
provide  a  user  interface  capable  of  presenting  the  equations  with  either  full  names  or  arguxnent 
substitutions. 
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6 .  Constraints  appropriate  for  each  computation  are  documented  in  the  Domain 
Constraint  Description  Text  entity.  If  more  rigor  is  desired  for  capturing  constraints,  one 
possibility  is  to  explicitly  identify  data  elements  participating  as  part  of  constraint  criteria  in  the 
Association  Member  entity.  These  elements  could  then  also  be  assigned  Argument  Names  that 
would  be  substituted  for  the  data  element  names  in  the  Constraint  Description  Text  column. 
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CHAPTER  4 

COMPLEX  DATA  STREAMS 


A.  DEHNmON 

1.  Complex  data  streams  use  strings  of  ordered  characters  or  bits  to  communicate 

information  through  a  variety  of  approaches,  including  graphics,  documents,  sound,  and  video. 
The  ordering  of  the  characters  or  bits  within  die  stream  is  important  for  correctly  formatting  and 
interpreting  die  information.  Some  special  escape  character  sequences  within  a  document,  for 
example,  may  trigger  special  processing  by  applications  that  interpret  die  stream  to  format  die 

text  (e.g.,  center,  bold,  and  underline  the  following  text). 

2.  Microcomputer  applications  (e.g.  word  processors,  spreadsheets,  graphics,  sound 
and  video  simulators,  and  hypertext)  originally  designed  to  boost  individual  productivity  often 
create  large  files  of  complex  data  streams.  These  applications  store  data  they  input  and  output  in 
non-relational  formats  because  the  relational  model  is  an  unsatisfactory  approach  for  supporting 
their  processing  requirements.  Several  relational  database  management  systems  have  extended 
their  data  types  to  include  Binary  Large  Objects  (BLOBs)  capable  of  storing  and  sharing  files 
created  by  these  various  applications.  The  BLOB  data  type  allows  die  DBMS  to  work  around  die 
issue  of  knowing  how  these  complex  data  streams  are  formatted. 

3.  Staring  complex  data  streams  in  database  management  system  as  BLOB  fields  does 
little  to  improve  their  shareability.  At  a  minimum,  additional  infonnation  must  be  correlated  with 
die  BLOB  to  describe  what  class  or  type  of  data  stream  it  represents  (e.g.,  Microsoft  word 
document.  Excel  spreadsheet,  sound  recording).  These  attendant  element*  should  W  standardized 
to  ensure  that  a  wide  variety  of  applications  can  correctly  initiate  procedures  to  access,  interpret, 
and  present  data  stored  in  the  BLOB  field. 

B.  CLASSIFICATION  OF  COMPLEX  DATA  STREAMS 

Complex  data  streams  include: 

1.  Documents.  Large  text-based  files  created  by  word  processors  or  text  editors. 
Documents  are  often  formatted  for  interpretation  and  manipulation  by  a  specific  application,  and 
commonly  contain  embedded  or  finked  BLOBs  (e.g.,  graphics  and  spreadsheets). 
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2.  Spreadsheets.  Tables  of  two  or  more  dimensions  usually  holding  numerical 
information.  Many  financial  accounting  needs  are  performed  on  computer  spreadsheets  to  utilize 
the  automated  cross  checking,  editing,  and  mathematical  processing  capabilities.  Applications 
which  create  spreadsheets  also  commonly  manipulate  the  data  to  produce  graphical  charts. 

3.  Graphics.  Simple  or  complicated  drawings.  CAD/CAM  systems  and  graphics 
programs  such  as  Mac-Draw  or  Visio  can  be  used  to  create  these  pictures. 

4.  Video  and  Sound.  Video  and  sound  digitally  recorded  and  manipulated  by  software 
under  user  direction. 

5 .  Hypertext  Compilations  of  various  text  video,  and  sound  linked  together. 
Applications  that  create  and  manipulate  hypertext  allow  users  to  review  various  topics  and 
seamlessly  jump  to  related  topics. 

C.  COMPLEX  DATA  STREAM  STANDARDIZATION  ISSUES 

1 .  Trends  toward  development  of  new  data  types  (e.g.  other  than  integer,  character, 
string,  and  date)  require  data  administration  to  extend  data  sharing  and  data  reuse  disciplines  to 
account  for  these  new  data  types.  Hies  produced  by  word  processors,  spreadsheets,  graphics 
applications,  and  other  productivity  improvement  applications  are  becoming  a  more  widely 
'shared'  resource  within  some  organizations  than  traditional  character  and  numeric  types  of  data 
extracted  from  databases.  Standards  need  to  be  defined  if  complex  data  streams  are  to  be 
effectively  shared  when  stored  in  BLOB  type  fields. 

2.  Standards  for  BLOBs  can  be  viewed  at  two  levels; 

a.  Internal  Storage  Format  Standards.  Within  the  types  of  BLOBs  being 
created,  various  standards  exist  to  increase  the  shareability  among  applications  in  the  same  product 
type.  For  example,  the  Standard  Generalized  Markup  Language  (SGML)  has  been  created  as  a 
formatting  language  in  word  processing  documents.  This  standard  facilitates  the  sharing  of 
documents  because  any  SGML  compliant  word  processor  cam  read  the  document  fife  Within  the 
graphics  arena,  various  standards  exist  for  the  organization  of  the  data  files.  These  standards  can 
serve  as  a  basis  for  any  graphics  program,  increasing  the  compatibility  between  graphics 
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program".  The  knowledge  of  such  standards  is  important,  and  organizations  should  encourage 
vendors  to  adopt  common  storage  formats. 


b.  Description  Standards.  Standards  should  be  developed  for  die  metadata 
associated  with  BLOBs.  These  standards  will  allow  data  administrators  to  manage  the  object's 
reuse,  regardless  of  internal  format  Three  issues  must  be  addressed: 


(1)  The  existing  application  types  will  increase  in  capability  and 
complexity,  with  die  potential  for  creating  composite  complex  data  streams.  The  use  of  multiple 
applications  to  create  one  final  product  (e.g.,  word  processor,  graphics  and  spreadsheet  application 
products  are  combined  to  produce  a  single  document)  has  already  placed  a  heavy  emphasis  on 
sharing. 


(2)  BLOBs  are  now  being  recognized  as  formal  data  types  that  can  be 
managed  and  reused  as  a  very  simple  form  of  information  object  Under  die  Object  Oriented 
paradigm,  for  example,  BLOBs  can  be  administered  as  encapsulations  of  methods  and  d»t» 
However,  procedures  for  administering  object  reuse  are  immature,  and  few  repository  tools  exist 
to  support  object  reuse. 

(3)  Object  Oriented  technologies  are  sold  largely  to  formalize  practices 
for  managing  object  reuse,  and  to  increase  productivity  of  system  analysis,  design,  and 
development  An  object  management  infrastructure  must  exist  to  support  object  search, 
discovery,  create,  and  store  activities  across  system  development  projects  if  these  reuse  objectives 
are  to  be  fulfilled. 

D.  MODEL  OF  DATA  REOUIRMENTS  FOR  BLOB  RKITSF. 

l.  Perspective 

The  logical  model  to  complex  data  streams.  Figure  4-1,  is  designed  to  track:  die 
applications  used  to  create  BLOBs,  and  to  identify  substitute  applications  of  reading  and 
further  manipulating  die  BLOBs. 
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Object  Class 


Object  Class  Name 


Object  Class  Description 


Application 


Application  TfUntifi^r 


Created  /Updated  by 

BLOB  Source 


Application  Idcatjfier(FK) 
Object  Class  Name(FK) 


Stored  in 


Library  Type  Code 


ConelatioB  Type  Code 


Object  Database 
/object  Name  (FK) 


Object  Rle 
Object  Name  (FK) 


.Table  Name 


Column  Name 


File  Name  J 


Objer  ~  iabase  Access  Annex 

/Object  Name  (FK) 

Key  Column  Name 


I  Accessed  Umg 


^Kcy  Column  Valoe  Text  J 


Figure  4-1  Preliminary  Logical  Data  Model  of  Data  Requirements  for 
Administering  Complex  Data  Streams  as  Reusable  Assets 
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2.  Semantic  Rules 

A  BLOB  is  created  by  an  application,  and  can  be  accessed  for  viewing  and  further 
manipulation  by  die  same  application  or  any  other  application  capable  of  parsing  the  format  under 
which  the  BLOB  is  stored.  A  model  designed  to  facilitate  BLOB  reuse  must  account  for  die 
following  inherent  characteristics  of  BLOBs  and  applications  that  create/manipulate  BLOBs: 

a.  A  many-to-many  relationship  exists  between  applications  and  the  different 
types  of  BLOBs  (e.g.,  document,  graphics,  and  spreadsheets)  they  can  create/manipulate. 

b.  A  many-to-many  relationship  exists  between  an  application  and  die 
format(s)  it  can  use  to  access  a  specific  type  of  BLOB.  One  standard  format  can  be  supported  by 
multiple  applications,  and  a  single  application  may  support  or  translate  multiple  formats. 

c.  A  BLOB  can  link  to  or  embed  other  BLOBs  (e.g.,  a  word  processing 
document  can  have  embedded  graphics). 

d.  The  manipulations  that  an  application  can  perform  on  a  BLOB  may  be 
constrained  by  the  syntax  of  the  format  in  which  the  BLOB  is  stored.  For  example,  a  word 
processing  application  will  often  not  edit  an  embedded  graphic.  It  may,  however,  allow  linking  to 
the  authoring  graphic  application  for  editing. 

e.  Cunendy  no  universally  accepted  standards  exist  for  formatting  die  various 
types  of  BLOBs  (e.g.,  word  processing,  spreadsheet,  graphics,  and  voice).  Although  there  is 
some  movement  to  provide  import  and  export  capabilities  to  share  files  across  different 
applications,  in  the  short  term  applications  will  continue  to  create  and  store  files  in  incompatible 
formats. 


3.  Relational  Model  Overview.  A  relational  model  in  Figure  4-1  supports  semantics 
described  above  using  11  entities.  These  entities  divide  into  two  groups: 

a.  Object  Instance  Description.  Five  entities  in  the  lower  half  nf  Figure  4-1 
describe  object  instances  (Le.,  data  streams)  registered  for  reuse  in  either  a  library  of  files  or  in  a 
database  repository.  Presumably  die  repository  is  managed  by  an  Object  Oriented  nr  a  Relational 
DBMS  that  would  store  the  information  in  BLOB  fields.  Data  for  these  five  entities  could  be 
populated  or  updated  as  a  part  of  registering  a  specific  object  (e.g.,  a  specific  diagram  or  chart)  for 
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reuse.  It  would  be  deleted  when  an  object  instance  is  removed  from  the  library.  The  parent  entity 
named  "object"  contains  information  that  allows  a  user  to  determine  what  application  created  tire 
object  (e.g.,  MacDraw  II),  what  type  of  object  it  is  (e.g.,  graphic),  and  what  format  is  used  to 
store  the  library  copy  (e.g.,  PICT).  Data  access  software  could  use  this  information  to 
automatically  retrieve  the  data  stream  from  the  library  using  location  data  in  either  the  Object  File  or 
die  Object  Database  and  associated  Object  Database  Access  Annex  entities.  Users  not  having  the 
requisite  application  on  their  workstation,  if  well  versed  in  the  capabilities  of  different  applications 
available  in  the  office,  could  identify  a  substitute  applications  to  access  tire  data.  The  Object 
Correlation  entity  records  what  objects  are  linked  or  embedded  with  other  objects  -  providing  some 
measure  of  reuse  within  the  library,  and  data  required  for  configuration  management  of  die  object 
instance. 

b.  Object  Class/Application  Description.  Six  entities  in  the  upper  half  of 
Figure  4-1  describe  object  classes  (e.g.,  graphics),  applications  that  create  instances  for  each  object 
class  (e.g.,  graphics  programs  such  as  MacDraw  n,  Visio,  or  Harvard  Graphics),  and  the  file 
formats  these  applications  can  accept  as  inputs  and  produce  as  outputs  (e.g.,  PICT).  A  database 
containing  this  information  would  allow  data  access  software  to  automatically  identify  gihstitnt* 
applications  for  accessing  a  specific  object  instance  stored  in  die  reuse  library.  This  information  is 
very  stable;  it  can  be  catalogued  each  time  an  application  is  purchased  as  a  supported  "standard"  for 
die  open  system  environment  (OSE).  The  documentation  captured  in  these  entities  and  middleware 
to  support  data  access  to  this  data  represents  a  benefit  provided  to  organizations  that  comply  with 
the  OSE  standards  adopted  by  the  organization. 

4.  Entity  Descriptions 

a.  Object  Class.  Specifies  die  type  of  objects  which  can  occur.  Example  types 
are  document,  graphics,  and  spreadsheet 

b.  Format  Identifies  and  describes  formats  supported  across  die  different 
applications  (standard,  and  proprietary)  used  to  store  BLOBs.  The  description  simply 
communicates  the  semantics  supported  by  a  format  without  attempting  to  convey  any  infirm »tirm 
about  the  syntax  used.  For  example,  a  description  tells  what  the  format  can  generally  support  in 
terms  of  object  classes  and  methods,  but  reveals  nothing  about  the  code  stored  in  position  1  or 
what  a  specific  sequence  of  special  characters  represents). 


4-6 


937 


c.  Application.  Documents  existing  applications  that  create  and/or  perform 
operations  on  BLOBs.  An  application  can  have  BLOB  Source  Application  and/or  Application 
Format  Conversion  capabilities. 

d.  BLOB  Source  Application.  Lists  all  the  Object  Classes  a  specific 
application  supports.  Some  applications  (e.g.,  Excel  and  Enable)  are  capable  of  producing  objects 
f«llin£  within  multiple  object  classes  (e.g.,  spreadsheet,  graphic,  and  document). 

e.  Application  Format.  Lists  all  formats  supported  bv  a  specific  BLOB  Source 
Application  Compatibility  among  BLOB  Source  Applications  is  detected  by  shared  formats  (e.g., 
MacDraw  n  and  Visio  are  compatible  graphics  applications  because  both  applications  operate  on 
files  stored  using  the  PICT  format). 

f.  Application  Format  Conversion.  Lists  all  conversions  that  a  BLOB 
conversion  application  supports  by  correlating  source  formats  with  allowable  target  format  options 
(e.g.,  Microsoft  Word  source  format  to  a  WordPerfect  target  format). 

g.  Object  Identifies  and  describes  all  objects  created  that  represent  reusable 
assets.  Each  object: 

(1)  Refers  to  its  source  application  through  the  Application  Identifier. 

(2)  Belongs  to  an  object  class  specified  by  die  Object  Class  Name 

attribute. 

(3)  Stores  information  in  a  specific  format  specified  by  the  Format 

Identifier. 

(4)  Has  special  locational  attributes  feat  direct  users  to  where  the 
authoritative  version  of  an  object  is  stored  based  on  differentiation  provided  by  a  library  Type 
Code.  The  model  shows  example  attributes  for  Database  and  File  type  libraries: 

(a)  Ohiftct  Describes  where  to  locate  an  object  stored 

within  a  BLOB  field  of  a  database  (e.g.,  what  table  and  column). 
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(b)  Object  Database  Access  Annex.  Lists  column  names  and 
column  values  for  identifying  a  unique  row  in  a  database  table  staring  a  specific  object 

(c)  Object  File.  Describes  where  to  locate  an  object  stored  as  a 
file  on  a  server  (e.g.,  Server  identifier,  and  file  name). 

h.  Object  Correlation.  Records  object  linkages  or  embedding.  Tf  the  linked 
and  embedded  objects  are  stored,  die  ability  to  track  changes  to  die  original  BLOB  is  required. 
Administrative  information,  such  as  a  create  date,  last  change  date,  and  version  number,  assigned 
to  each  Object  instance  could  be  used  to  track  updates, 

5.  An  Extension  on  Methods.  If  the  six  entities  in  the  top  half  of  Figure  4-1  are  used 
to  support  automated  capabilities  for  identifying  substitute  applications  far  accessing  and 
displaying  die  data,  then  capabilities  of  die  substitute  application  to  process  the  data  may  become  an 
important  discriminator  for  selecting  among  multiple  substitutes.  Figure  4-2  introduces  two  new 
entities  into  die  model  described  above  that  record  these  capabilities: 

a.  Method.  Identifies  and  describes  the  types  of  actions  that  can  he  performed 
on  different  types  of  objects  (e.g.,  play,  edit,  display). 

b.  Method- Application  Format  Correlation  Identifies  the  arrinnt  for 

a  specific  Application  Format  This  information  communicates  constraints  for  compatibility  across 
different  Application  Formats  (e.g.,  visio  can  display  and  edit  a  graphic  in  die  PICT  format, 
while  WordPerfect  can  only  display  die  iphic  in  the  ‘WPG’  format). 
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Application  Format  Conversion 
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Application  Identifier  (FK) 

Format  Identifier  Source  Fonnat(FK) 
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Application 

Format 


Object  Name 


Application  Identifier  (FK)  Create  Date 

Object  Class  Name(FK)  Create  Time 

Format  IdendfieKFK)  Modified  Date 

Library  Type  Code  Modified  Time 


I  Convened  by 


Format 


Links/ 

Embeds 


Stored  in 


Library  Type  Code 


Object  Correlation 

Object  NamePrimary 
Object  Name(FK) 
Object  Name.  Secondary 
Object  Name(FK) 


l  Correlation  Type  Code 


Object  Databaae 
Objea  Name  (FK) 

.  Table  Name 


Column  Name 


Object  File 

f . """"  1 

Objea  Name  (FK) 

.Server  Identifier 


File  Name  J 


Objea  Database  Access  Annex 

''Objea  Name  (FK) 

Key  Column  Name 
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I  Accessed  Using 


Figure  4-2  Methods  Extension  of  Model  for 
Administering  Complex  Data  Streams 
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E.  EXAMPLE  COMPLEX  DATA  STREAM  REUSE  APPLICATION 

1 .  Figure  4-3  presents  an  example  application  for  Complex  Data  Stream  reuse  using 
graphic,  spreadsheet,  and  document  types  of  information. 

2.  A  WordPerfect  document  named  'Strategy  Plan'  uses  spreadsheet  and  graphics 
information  that  are  also  cataloged  separately: 

a.  'Projected  Expenses'  is  a  LOTUS  1-2-3  spreadsheet  saved  in  a  relational 
database  using  a  BLOB  type  field. 

b.  'Agency  Organization  Chart'  is  a  MacDraw  n  graphic  stored  in  a  graphics 
file  in  a  directory  established  for  reusable  graphics. 

3.  The 'Strategy  Plan' is  stored  in  a  WordPerfect  document  in  a  text  library  established 
for  reusable  documents. 

F.  MODELED  DOCUMENTATTON  OF  TOE  COMPLEX  DATA  STREAM 

1.  Figure  4-4  uses  the  model  developed  in  Figure  4-1  to  capture  the  example  complex 
data  stream  application. 

2.  Each  of  the  object  classes  defined  in  this  report  (Le.,  document,  graphic, 
spreadsheet,  and  others)  are  identified  in  die  Object  Class  entity. 

3.  A  sample  of  applications  used  to  create  and  manipilat*  BLOBs  (Le.,  Application  '•••• 

Category  Code  =  'Source')  is  defined  in  the  Application  entity  along  with  one  application  for 
converting  BLOBs  across  a  set  of  widely  used  formats  (Le.,  Application  Category  Code  = 
Conversion'  for  the  application  named  'MacLink').  The  application  identifier  is  used  as  a  key  to 
relate  information  in  the  Application  entity  to  information  in  the  BLOB  Source  Application, 
Application  Format  Conversion,  and  Application  Format  entities  (e.g.,  Application  ■  ’4’ 

specifies  WordPerfect,  DOS,  Version  5.1). 

4.  Sample  records  in  the  Application  Format  entity  for  the  WordPerfect,  Microsoft 
Word,  MacDraw,  Visio,  LOTUS  1-2-3,  and  Excel  applications  illustrate  bow  compatibility 
these  source  applications  can  be  inferred  from  file  formats  shared  across  die  different 
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Figure  4-4  Documentation  of  the  Example  Binary  Large  Objects  in 
the  Model  for  Administering  Reuse  of  Complex  Data  Streams 
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applications  (e.g.,  WordPerfect  5. 1  can  access  and  store  documents  in  Microsoft  Word  3.0 
formats,  but  Microsoft  Word  will  not  read  or  write  WordPerfect  documents). 

5 .  Sample  records  in  the  Application  Format  Conversion  entity  for  the  MacLink 
application  illustrate  how  BLOBs  can  be  shared  across  applications  which  otherwise  show  little  or 
no  compatibility.  For  example,  Microsoft  Word  3.0  files  (i.e.,  format  'MSW40')  can  be  convened 
to  WordPerfect  5.1  files  (Le.,  format  WP51')). 

6.  The  three  reusable  objects  described  for  the  example  are  recorded  in  the  Object 
entity.  Use  of  the  'Organization  Chan'  graphic  and  Projected  Expenses'  spreadsheet  by  the 
'Strategy  Plan'  document  is  depicted  in  the  Object  Correlation  entity.  Location  information  for 
each  of  die  objects  is  documented  in  the  Object  Database  and  Object  File  entities. 

7.  A  small  sample  of  data  in  the  Verb- Application  Format  Correlation  entity  related  the 
WPG'  format  used  for  WordPerfect  graphics  and  the  PICT  format  shared  between  MacDraw  II 
and  Visio  illustrates  how  object  manipulation  constraints  can  be  recorded.  The  Visio  supports 
'Create',  'Edit',  and  "Display'  actions  on  the  PICT  format,  while  WordPerfect  only  supports 
Display'  actions  on  the  WPG'  format  (WPG'  format  needs  to  be  confirmed). 

G.  ROLE  OF  DATA  STANDARDIZATION  IN  SUPPORTING  BLOB  REUSE 

1 .  It  will  take  some  time  to  develop  standard  formats  for  documents,  graphics, 

spreadsheets,  and  other  classes  of  BLOBs.  However,  concepts  represented  in  tire  relational  data 
model  presented  in  Figures  4-1  and  4-2  are  currently  being  implemented  in  widely  varying  and 
incompatible  ways  by  a  number  of  commercial  applications  (e.g.,  Microsoft's  OLE,  IBMs  IRMS, 
Lotus  Notes).  Each  time  a  proprietary  variant  is  implemented,  tire  prospects  for  implementing 
enterprise-wide  approaches  for  sharing  complex  data  streams  as  corporate  assets  get  more 
complex;  the  codes  used  to  identify  different  object  classes,  application^  and  formats  will  vary 
across  die  implementations.  To  mmtmiac  the  impact  of  proprietary  snifttipps  on  sharing  data 
streams  across  the  enterprise,  standards  are  needed  for  six  of  fee  attributes  appearing  in  Figures  4- 
1  and  4-2: 

a.  Object  Class  Name 

b.  Application  Identifier 

c.  Application  Name 

d.  Operating  Environment 
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d.  Format  Identifier 

e.  Method  Identifier 

2.  These  elements  are  likely  to  be  developed  by  many  middleware  applications 
supporting  the  reuse  of  BLOBs.  They  also  have  domains  of  values  that  will  be  defined  differently 
in  each  case  unless  proactive  action  is  taken  for  standardizing  die  elements. 

3 .  Interest  in  standardization  of  these  elements  extends  beyond  die  boundaries  of  DoD, 
and  it  would  be  in  DoD's  interest  to  promote  a  project  to  standardize  these  elements  at  a  national 
level  through  die  American  National  Standards  Institute  (ANSI). 
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CHAPTER  5 

ASSEMBLIES 


A. 


Assemblies  represent  entities  which  have  relationships  to  themselves  (Le.t  instances  within 
the  entity  relate  recursively  to  other  instances  within  the  same  entity).  Organization  structures, 
equipment  assemblies  and  subassemblies,  and  geographic  terrain  features  such  as  roads,  rivers, 
and  facilities  all  represent  examples  of  assemblies.  Assemblies  often  represent  dominant  entities 
which  commonly  appear  across  multiple  functional  data  models.  The  relationships  assembly 
fnririfg  have  to  themselves  are  commonly  called  recursive  relationships. 

B.  REUSABILITY  ISSUES 

1 .  Model  reuse  has  largely  been  viewed  from  the  perspective  of  functional  or  subject 

area  oriented  classifications  (e.g.,  personnel,  logistics,  finance,  and  operations).  Assemblies 
represent  commonly  recurring  objects  that  span  functional  areas  and  provide  focal  points  for  model 
integration. 


2.  Elements  of  recursion  found  within  assemblies  are  intellectually  complex,  and  are 
treated  differently  in  different  models.  In  fact,  much  of  die  knowledge  gained  by  the  modeler  in 
discovering  the  correct  representation  of  an  assembly  often  never  gets  communicated  through  the 
depiction  of  entity  relationships;  rather,  they  are  represented  in  edits  developed  for  add,  change, 
and  delete  operations  or  event  triggered  alerts.  These  roles  should  be  communicated  with  the 
model,  possibly  as  extensions  using  structured  English  or  predicate  catenins 

3.  Analogous  to  the  improvement  in  program  readability  brought  about  by  structured 
programming,  standard  templates  for  the  treatment  of  recursion  would  improve  model  readability 
for  assemblies.  Possible  elements  of  these  templates  are: 

a.  Standard  entity  relationship  profiles  for  modeling  recursion.  Examples  for 

one-to-many  and  many-to-many  entity  relationship  profiles  for  recursive  relationships  are  depicted 
in  Figure  5-1.  Standard  profiles  developed  for  treating  recursive  relationships  in  data  modeling 
would  be  analogous  to  standard  structured  programming  constructs  developed  for  control  logic 
such  as  VO  WHILE',  VO  FOR',  and  VO  UNTIL'  looping. 
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Intelligent  Key:  One-to-many 
recursive  relationship  based  on 
intelligence  embedded  in  the 
coded  values  of  the  key  (e.g.,  0.0, 
1.0, 1.1, 1.1.1, 1.1.2, 1. 1.2.1) 


Foreign  Key  Role  Element: 
One-to-many  recursive 
relationship  based  on  linking 
foreign  key  of  a  child  entity 
instance  to  the  primary  key  of 
another  parent  entity  instance. 


Child  Correlation  Entity: 
Many-to-many  recursive 
relationship  correlating  a  child 
entity  having  primary  and 
secondary  foreign  key  role 
elements.  The  names  assigned 
to  these  foreign  keys  indicate  the 
nature  of  die  relationship 
between  entity  instances  in  the 
parent  entity. 


Association:  Many-to-Many 
Recursive  Relationship  based  on 
creation  of  an  independently 
identified  Association  entity. 

The  association  entity  is  related 
to  the  parent  entity  using  an 
Association  Member  correlation 
entity.  The  association  identifier 
is  a  fabricated  element  which 
ultimately  is  system  maintained. 
Roles  are  identified  by  assigning 
.allies  to  an  Association  Role 
Code  in  the  Association  Member 
entity. 


Parent  Entity 


Parent  Entity 


Figure  5-1  Example  Alternative  Profiles  for  Modeling  Recursion 
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b .  Standard  vocabulary  for  naming  associative  entities  designed  to  support  a 
recursive  relationship  (e.g.,  suffixes  to  the  entity  name,  such  as  ‘Correlation’,  'Association'  and 
'Association  Member1).  If  used  in  a  standard  way,  these  words  would  alert  readers  that  the  entities 
are  designed  to  support  a  recursive  relationship. 

c.  Standard  vocabulary  terms  for  naming  relationships  supporting  recursion 
within  a  single  entity. 

D.  REUSABHJTY.GUIDANCE 

1 .  Guideline  templates  on  structured  modeling  far  Assemblies  should  be  developed. 
Figures  5-2  through  5-5  represent  a  starter  set  of  templates  which  expand  on  the  profiles  identified 
in  Figure  5-1.  Evaluation  criteria  need  to  be  developed  as  part  of  die  guidelines  to  help  modelers 
select  among  die  templates.  Five  evaluation  criteria  for  selecting  among  die  templates  shown  in 
Figures  5-2  through  5-5  follow: 

a.  Simplicity  of  Syntax.  This  criteria  measures  the  ability  of  iha  template  in 
represent  recursion  without  introducing  a  lot  of  new  entities  and  attributes  into  die  model.  A  few 
entities  and  attributes  are  better  than  many  entities  and  attributes.  For  example,  the  Intelligent  Key 
template's  approach  would  score  well  by  this  criteria  because  it  introduces  no  new  entities  or 
attributes.  In  contrast,  the  Association  approach  introduces  two  new  entities  and  three  new 
attributes,  and  would  rate  lower  by  this  criteria. 

b.  Maintainability  This  criteria  measures  die  difficulty  of  maintaining 
recursive  relationships  among  data  instances  using  a  template.  Lowering  die  requirements  to 
cascade  an  update  to  multiple  records  is  particularly  desirable.  Notice,  for  example,  that  if  the 
Intelligent  Key  named  'Work  Breakdown  Identifier1  (Figure  5-2,  part  C)  changes  far  a  High  level 
node  (e.g.,  change  2.0  to  5.1),  the  update  will  cascade  to  all  lower  level  nodes  (Le.,  2.1,  IX  and 
2.3  would  change  to  5.1.1, 5.1.2,  and  5.13  respectively).  This  is  an  undesirable  characteristic  of 
the  Intelligent  Key  template,  In  contrast,  reassigned  key  values  in  a  Conelatior  Entity  template 
(Figure  5-4)  do  not  cascade  to  other  records;  this  makes  the  Correlation  Entity  a  mote  <WnHlr 
template  from  the  maintainability  perspective. 

c.  Fkxflwlitv.  This  criteria  measures  the  ability  of  a  twnpUtf  to  support 
'many-to-many'  as  well  as  'ooe-to-many'  cardinality  for  recursive  relationships.  If  there  are 
possible  exceptions  to  a  ooe-to-many  rule,  it  is  best  to  model  die  relationship  using  a  template  tint 
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A.  General  Syntax 

Parent  Entity _ 

Intelligent  Key 

Non-kev  Attributes 


B.  Example  Work  Breakdown  Structure  For  Budding  and  Airplane 


Build  Aircraft 


1.1  Assemble  Main  Body 
13  Construct  Front  Wings 
13  Construct  Tail 


2.1  ConstructEngme 
12  Build  Fuselage 
23  Develop  Engine  Mounts 


3.0 

Build  Weapons 
System 

-  3.1  Build  Missile  Launcher 
•  33  Develop  Targeting  System 
.33  Develop  Firing  System 


C  Modeled  with  Intelligent  Key 

Work  Breakdown  Structure 


Work  Breakdown  Identifier 


Task  Name 


D.  Example  Instance  Table 

Work  Breakdown  Structure 


Work 

Breakdown 

Identifier  Task  Name 


Build  Aircraft 
Build  Airframe 
Assemble  Mam  Bode 
Construct  Front  Wings 
Construct  Tail 
Build  Bower  Unit 
Construct 


Figure  5-2  One-to-Many  Recursive  Relationship  Modeled  with  Iwtrfiigmt  Key 
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Foreign  Key  Role 
Element 


A.  General  Syntax 
Patent  Entity 


Primary  Key 


B.  Example  Organization  Structure 


Corporate 

Executive 


Construction 

Shipping 

Maintenance 

Supply 


C  Modeled  with  Foreign  Role  Key 
Organization  Structure 
I  Organization  Name  1 


New  Markets 
•  Existing  Cheats 
Customer  Research 


D.  Example  Instance  Table 

Organization  Structure 


Organization  Name  I  Pmw 


Figure  5-3  One-to-Many  Recursive  Relationship  Modeled  with 

Foreign  Role  Key 
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Child  Correlation  A.  General  Syntax 
Entity  _  _ 


Parent  Entity 


Primary  Key 


B.  Example  Equipment/ Assemblies  Structure 

Equipment  Assembly 


Chfld  Correlation  Enti 


Primary  Role.Primary  KeyCFK)  ■ 
Secondary  RokJrimary  Key(FK)| 


2  1/2  Ton  Truck 


-2  1/2  Tod  Truck  Framer 
“Power  Assembly  mg— 
“Engine  ^ 

“Winch  X.  \ 
-M60  Tank  Chasey^^^ 
-Targeting  System _ 


Cmbt  Engr  Vehicle 


Generator 


Taring 
*Arm 
*  Gasket 
(Lining 

I'Commoc  1/4’"  Medium 
Machine  Bolt 
Rocker 
■BaD 

•Manifold 


C  Modeled  with  Correlation  Table 

Equipment/Part 


Equipment  Item  Identifier 


Equipment  Item  Description 


Equipment/Part 
Assembly  Correlation 


D.  Example  Instance  Table 

Equqxnent/Part 


Kqni[mq|t  Turn  Tit-ntifi-r 


2  1/2  Too  Trade 

Cmbt  Engr  Vehide 

Winch 

Cam 

Rocker 


Major  Equipment  Item 
Identifier JEquqxnent  Item  Identifier<FK) 
Minor  Equipment  Item 
Identifier  Equipment  Item  IdentifieKFK) 


Equipment/Part  Assembly  Correlation 


I 


Major  Equipment 
Tim  identifier. 


Minor  Equipment 

Iwn  Iriwiiififr 


2 1/2  Ton  Truck  Winch 

2 1/2  Ton  Track  Gun 

Cmbt  Engr  Vehide  Winch 

Cam  Rocker 


Figure  5-4  Many-to-Many  Recursive  Relationship  Modeled  with 

Correlation  Entity 
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Association 


A.  General  Syntax 


Primary  Key 

Association  Identifier 

Association  Type  Code 

B.  Example  Associations  Among  Employees 

Employee  Association  Type 


Association  Member 

Association  Idcntifia(FK) 
Primary  Key(FK) 

Assodaiioo  Role  Code 


Supervisor 


Eliot  Jones 
Aimita  Smith  — 
Steve  Black  — 
Scott  Wbooton  • 
John  Doe  <aaes 
Sam  Smitb^sC 

Ray  James - 

Barbara  Moore. 
George  Doe  — 


Example  Association  Documentation 


Assigned  To 


:  Spouse 


:  Sibling 


ree  Association 


Employee 


Employee 

Number 

Employee  Name 

501 

502 

503 

Eliot  Jones 

Aimita  Smith 

Steve  Black 

504 

Soon  Wbooton 

505 

Jobs  Doe 

506 

Sam  Smith 

507 

Ray  James 

508 

Barbara  Moore 

509 

George  Doe 

Association 

Identifier 

Association 

Type  Code 

001 

Supervisor 

002 

Supervisor 

003 

Assigned  To 

004 

Sibling 

005 

Spouse 

006 

Mentor 

Employee  Association  Member 


Identifier 


Employee 

Number 

Association 
Role  Code 

501 

Manager 

504 

Sobanhnaie 

505 

Subordinate 

506 

Subordinate 

502 

Manager 

505 

Subordinate 

508 
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supports  many-to-many  relationships.  Both  the  Intelligent  Key  (Figure  5-1)  and  die  Foreign  Role 
Key  (Figure  5-2)  templates  are  incapable  of  supporting  many-to-many  cardinality,  and  score  low  in 
their  flexibility.  Because  the  Correlation  Entity  (Figure  5-4)  and  the  Association  (Figure  5-5) 
templates  both  support  many-to-many  as  well  as  one-to-many  cardinality  for  the  recursive 
relationships,  they  are  preferable  alternatives  from  the  flexibility  perspective. 

d.  Extensibility.  This  criteria  measures  die  ability  of  a  template  to  adapt  to  new 
types  of  recursion  after  design  or  implementation  of  the  database.  Each  of  die  templates  that  force 
the  modeler  to  either  embed  intelligence  into  die  key  or  into  die  name  of  a  'role  element'  (Le., 
Intelligent  Key,  Foreign  Role  Key,  and  Correlation  Entity  templates)  place  some  limitations  on  die 
extensibility  of  die  recursive  relationship.  The  relationship  is  bounded  to  some  degree  by  the  role 
element's  name.  For  example,  in  Figure  5-3  part  C,  the  element  named  'Parent  Organization' 
restricts  the  relationship  to  support  the  definition  of  a  Tiigher  level  authority'.  Sibling  type 
relationships  (e.g.,  supplier/customer)  could  not  be  supported.  A  similar  type  of  restriction  is 
embedded  in  die  names  'Major  Equipment  Item  Identifier*  and  Minor  Equipment  Item  Identifier* 
assigned  to  role  elements  for  the  Correlation  Entity  template.  These  names  prohibit  die  relationship 
from  tracking  'standard'  and  'substitute'  parts.  The  multiple  types  of  relationships  shown  by 
example  for  the  Association  template  (e.g..  Supervisor,  Sibling,  and  Spouse  in  Figure  5-5,  parts  B 
and  C)  illustrate  extensibility  possible  when  die  roles  can  be  designated  by  value  assignments 
rather  than  name  assignments  (e.g.,  values  for  the  Association  Role  Code  in  die  Association 
Member  entity). 


e.  Tntrilftcmal  Complexity.  This  criteria  measures  how  easily  the  template 
communicates  model  semantics.  A  compromise  position  must  be  discovered  for  reducing  clutter 
introduced  by  embedding  role  information  in  entity  names  and  attributes  names,  and  avoiding  of 
intellectual  complexity  introduced  by  abstraction.  The  Association  template  encourages 
relationship  abstraction;  this  results  in  many  fewer  entities  and  elements  than  die  Correlation  Entity 
template.  However,  it’s  important  to  note  that  entities  and  attributes  are  reduced  by  loading 
business  rules  into  the  domains  of  allowable  values  assigned  to  role  elements  in  the  Association 
template.  This  makes  the  overall  model  easier  to  understand  in  general,  but  more  difficult  to 
understand  in  detail.  When  the  Correlation  Entity  template  is  used  and  roles  are  through 

die  entity  or  attribute  names,  users  must  grasp  the  meaning  of  many  more  entities  and  attributes 
before  formulating  the  SELECT  clause  of  a  query.  When  the  Association  template  is  used  and 
roles  are  assigned  as  attribute  values,  die  user  must  grasp  the  meaning  of  many  more  domain 
values  before  formulating  the  WHERE  clause  of  a  quay.  This  gives  credence  to  the  idea  that  data 
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modelers  must  be  concerned  about  domain  values  because  they  always  relate  to  a  more  detailed  set 
of  business  rules  than  entity  relationship  diagrams  are  designed  to  communicate. 

2.  As  suggested  in  Figure  5-6,  no  single  template  can  be  declared  the  "standard"  or 
"preferred"  approach  for  all  situations.  Just  as  a  programmer  must  decide  which  construct  to  use 
in  controlling  program  logic  (e.g.,  DO  WHILE'  versus  DO  FOR*),  modelers  must  decide  which 
template  is  appropriate.  Just  as  some  algorithms  are  complex  enough  to  require  nesting  of  different 
control  logic,  assemblies  may  be  complex  enough  to  require  merging  of  several  templates. 

3 .  Assembly  type  objects  should  be  identified  within  functional  models  and  separated 
for  reuse  independently  of  the  functional  model.  The  following  criteria  are  provided  to  help 
identify  assemblies  within  a  data  model: 

a.  An  independently  identified  entity  has  numerous  one-to-many  relationships 
oriented  away  from  the  entity. 

b.  The  entity  has  one  or  multiple  recursive  relationships  associated  with  it 

c.  The  entity  appears  to  exist  in  different  functional  models. 

4.  Use  of  assemblies  by  various  functional  data  models  should  be  tracked  to  support 
configuration  management  of  die  assembly  as  its  semantics  become  mote  clearly  understood  and 
focused  with  each  reuse. 
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^^^^Altereative 

Evaluation 

Criteria 

Intelligent 

Key 

Foreign  Key  Role 
Element 

Child 

Correlation 

Entity 

Association 

Simplicity  of  Syntax 

•  •  •  • 

•  •  • 

•  • 

• 

Maintainability 

• 

•  •  • 

•  •  • 

•  •  • 

Flexibility 

• 

•  • 

•  •  • 

•  •  • 

Extensibility 

• 

• 

•  • 

•  •  •  • 

Intellectual  Complexity 

•  • 

•  •  • 

•  •  • 

•  • 

Legend 

•  -  Poor 

••  -Fair  •••  -Good  ••••  -  Excellent 

Figure  5-6  Evaluation  of  Alternative  Templates  for  Representing 
Recursive  Relationships  in  Assemblies 
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APPENDIX  B 
DEFINITIONS 


1 .  Assemblies.  Data  structures  which  include  recursive  relationships  (Le.,  instances  within 
the  entity  are  related  to  other  instances  within  the  same  entity).  Organization  structures,  roads, 
buildings,  and  equipment  part  assemblies  are  all  examples  of  assemblies. 

2.  Attribute.  A  property  or  characteristic  of  an  entity;  for  example,  COLOR,  WEIGHT,  SEX. 
Also,  a  property  inherent  in  an  entity  or  associated  with  that  entity  for  database  purposes.  (HPS 
Pub  11-3  (reference  (a))) 

3.  Chain.  See  Data  Chain. 

4.  Complex  Data  Element  A  data  element  that  cannot  be  fully  described  as  a  single  attribute 
within  a  data  model. 

a.  Composite  Data  Elements.  Data  dements  which  embed  intelligence  about  multiple 
concepts  in  their  names,  definitions,  and  domains. 

b.  Derivations.  Data  elements  representing  concepts  computed,  aggregated, 
transformed  or  inferred  from  the  values  of  one  or  more  other  data  elements. 

c.  Data  Strr-flniR  Bundles  of  information  carried  in  sequence  which  represent 
information  in  a  variety  of  forms  (e.g.,  graphics,  voice,  text  documents,  and  spreadsheets). 

5.  Composite  Data  Element.  A  data  element  designed  to  communicatr  information  about  more 
than  one  concept  by  embedding  intelligence  in  the  name  or  the  coding  of  values.  See  Data  Chain, 
Data  Coupling,  Multipurpose  Data  Element,  and  Heterogeneous  Domain 

6.  Coupled  Data.  See  Data  Concept  Coupling. 

7.  Data-  A  representation  of  facts,  concepts,  or  instructions  in  a  fimaliMH  manner  ^  liable 
for  communication,  interpretation,  or  processing  by  humans  or  by  antomatir  m*ang  (FIPS  Pub 
1 1-3  (reference  (a))) 

8.  Data  Administration-  That  function  of  the  organization  which  oversees  the  management  of 
data  across  all  functions  of  the  organization,  and  is  responsible  for  central  information  planning 
and  control.  (NBS  Special  Pub  500-149  (reference  (b») 

9.  Data  Attribute.  A  characteristic  of  a  unit  of  data  such  as  length,  value,  or  method  of 
representation.  (FIPS  Pub  11-3  (reference  (a))) 

10.  Data  Chain.  A  composite  data  element  that  links  an  ordered  set  of  concepts  within  its  coded 
values  (e.g..  Equipment  Order  Code  with  sample  Domain  (AB001,  AB002,  AC001,  AC002) 
where  fire  first  two  positions  identify  die  type  of  equipment,  and  the  last  four  positions  identify  die 
order  number  for  that  type  of  equipment). 

11.  Data  Concept  Coupling.  The  embedding  of  two  or  more  concepts  within  a  data  element's 
name  or  domain  of  allowable  values. 
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a.  Coupled  Concepts  in  the  Name.  Elements  with  domain  values  for  two  or  more 
other  elements  embedded  in  their  names  (e.g.,  Materiel  Inventory  Second  Fiscal  Year  Authorized 
Quantity  conveys  domain  values  for  two  concepts  it  its  name:  Fiscal  Year  with  Domain  (1, 2, 3, 
...),  and  Inventory  Status  Name  with  Domain  (Authorized,  Required,  Damaged,  ...)).  This 
element  should  be  reformulated  to  cany  at  only  set  of  domain  values  in  the  name,  and  only  if  the 
domain  is  stable  and  has  fewer  than  ten  values. 

b.  Coupled  Concepts  in  the  Domain.  Elements  with  domain  values  that  are  not 
mutually  exclusive  (e.g.,  Plan  Objective  Rating  Code  with  Domain  (A  ^Priority  1,  Easy; 
B=Priority  2,  Easy;  C=Priority  1,  Difficult,  D=Priority  2,  Difficult, ...)).  This  element  should  be 
reformulated  as  two  elements:  Plan  Objective  Priority  with  Domain  (1, 2, 3, ...)  and  Plan 
Objective  Rating  Name  with  Domain  (Easy,  Moderate,  Difficult, ...) 

12.  Data  Dictionary.  A  specialized  type  of  database  containing  metadata  managed  hy  a  Haw 
dictionary  system;  a  repository  of  information  describing  the  characteristics  of  data  used  to  d^gn 
monitor,  document,  protect,  and  control  data  in  information  systems  and  datahaws;  and  application 
of  a  data  dictionary  system.  (FIPS  Special  Pub  500-152  (reference  (c)». 

13.  Data  Element  A  named  identifier  of  each  of  the  entities  and  their  attributes  that  are 
represented  in  a  database.  (FIPS  Pub  11-3  (reference  (a))) 

14.  Data  Element  Formulation.  The  design  of  a  data  element  in  terms  of  it's  name,  definition, 
type  (e.g.,  character,  date,  integer,  decimal),  length,  domain  of  allowable  values,  Hat?  steward 
specification,  security  characteristics  and  other  attributes  as  required  to  manage  die  data  element  as 
a  reusable  asset 

15.  Data  Element  Mapping.  Documentation  describing  how  two  or  more  data  element 
formulations  overlap  in  meaning. 

16.  Data  Element  Standardization  The  process  of  documenting,  reviewing  and  approving 
unique  names,  definitions,  characteristics  ami  representations  of  data  elements  according  to 
established  procedures  and  conventions. 

17.  Data  Entity.  An  object  of  interest  to  the  enterprise,  usually  tracked  by  an  automated 
system.  (NBS  Special  Pub  500-149  (reference  (b))) 

18.  Data  Model  In  a  database,  the  user's  logical  view  of  die  data  in  contrast  to  the  physically 
stored  data,  or  storage  structure.  A  description  of  die  organization  of  data  in  a  manner  that  reflects 
the  information  structure  of  an  enterprise.  (FIPS  Pub  11-3  (reference  (a))) 

a-  Logical  Data  Model.  A  model  of  the  data  stores  and  flows  of  the  organization 
derived  from  the  conceptual  business  model.  (NBS  Special  Pub  500-149  (reference  (b))) 

b.  Physical  Data  Model  A  representation  of  die  technologically  independent 
requirements  in  a  physical  environment  of  hardware,  software,  and  network  configurations 
representing  them  in  tire  constraints  of  an  sting  physical  environment. 

19.  Data  Steward-  The  person  or  group  that  manages  the  development,  approval,  and  use  of 

data  within  a  specified  functional  area,  ensuring  that  it  can  be  used  to  satisfy  data  reauiiements 
throughout  the  organization.  ^ 

20.  Data  Structure-  The  logical  relationships  which  exist  among  unit*  of  data  and  the 
descriptive  features  defined  far  those  relationships  and  data  units;  an  mstann?  or  orntn^m^  of  a 
data  model.  (NBS  Special  Pub  500-152  (reference  (c))) 
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21.  Database.  A  collection  of  interrelated  data,  often  with  controlled  redundancy,  organized 
according  to  a  schema  to  serve  one  or  more  applications;  the  data  are  stored  so  drat  they  can  be 
used  by  different  programs  without  concern  for  the  data  structure  or  organization.  A  common 
approach  is  used  to  add  new  data  and  to  modify  and  retrieve  existing  data.  (FIPS  Pub  1 1-3 
(reference  (a))) 

22.  Dictionary.  See  Data  Dictionary. 

23.  DqD  Data  Model.  A  corporate  level  data  model  developed  based  on  the  integration  of  data 
models  developed  within  individual  functional  areas. 

24.  Domain  The  set  of  permissible  data  values  from  which  actual  values  are  taken  for  a 
ppiticular  attribute  or  specific  d*>ta  element  In  a  relational  database,  all  of  the  permissible  tuples  for 
a  given  relation.  (FIPS  Pub  11-3  (reference  (a))) 

a.  Onwal  Domain.  The  permissible  data  values  allowed  in  representations  of  a  data 
element  defined  in  terms  of  die  character  set  which  can  be  used;  e.g.,  A-Z,  0-9,  etc. 

b.  Specific  Domain.  An  enumerated  set  of  values  allowed  in  data  representations  of  a 
data  element;  e.g.,  Friday,  Saturday,  Sunday. 

23.  Entity.  See  Data  Entity. 

26.  Information  System.  The  organized  collection,  processing,  maintenance,  transmission, 
and  dissemination  of  information  in  accordance  with  defined  procedures,  whether  automated  or 
manual  (DoDD  5200.28  (reference  (e)),  modified) 

27.  Metadata.  Information  describing  the  characteristics  of  data;  data  or  information  about  data; 
descriptive  information  about  an  organization's  data,  data  activities,  systems,  and  holdings.  (NBS 
Special  Publications  500-152  (reference)  (c))). 

28.  Migration  Data.  Data  from  or  within  a  migration  system.  See  also  Migration  System. 

29.  Migration  System.  An  existing  automated  information  system,  or  a  planned  and  approved 
automated  information  system,  that  has  been  officially  designated  to  support  standard  processes  for 
a  functional  activity  applicable  DoD-wide  or  Component-wide. 

30.  Multiple  Purpose  Element  Elements  formulated  to  have  multiple  meanings  based  on  the 
context  of  the  record  or  values  held  by  other  fields  in  die  record  (e.g..  Equipment  Stewardship 
Assignment  Code  with  Domain  (AO= Admin  Office,  ES=  Engr  Shop, ...  other  organizations) 
when  the  Quantity  On-hand  >  0,  and  Domain  (PP  =  Planned  Procurement,  ET=Exchange  Turn-in, 
...  other  status  codes)  when  the  Quantity  On-hand  =  0). 


31.  Nonstandard  Data  Element.  Any  data  element  that  exists  in  a  system  or  application 
program  and  does  not  conform  to  the  conventions,  procedures,  or  guidelines  established  by  the 
organization. 


32.  Standard  Data  Element.  A  data  element  which  has  been  submitted  formally  far 
standardization  in  accordance  with  the  organization's  data  element  standardization  procedures. 
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APPENDIX  C 

DATA  ELEMENT  GROUP  CLASSIFICATIONS 


A.  INTRODUCTION 

This  appendix  describes  how  the  data  models  described  in  Chapters  2  and  3  of  this  manual 
may  be  used  to  document  multiple  levels  of  security  or  sensitivity  for  specific  data  elements  when 
considered  in  various  groupings  of  other  data  elements. 

B.  EXAMPLE  CLASSIFIED  DATA  ELEMENT  COMBINATIONS 

A  data  element  may  be  combined  with  other  data  elements  in  a  wide  variety  of  ways  to 
produce  information.  The  element  may  normally  be  considered  as  describing  relatively  low  risk 
information;  however,  die  element  may  participate  in  some  combinations  of  elements  Oat 
collectively  describe  sensitive  data.  Figure  C-l  summarizes  three  examples  of  three  levels  of  data 
security  which  commonly  occur  in  DoD: 

1.  Classified  Data  Elements.  Individual  data  elements  may  transmit  information  which 
is  viewed  as  classified.  In  these  circumstances,  the  data  element’s  security  classification  rating 
(e.g.,  classified,  secret,  top  secret)  can  be  assigned  as  an  attribute  of  die  data  element  itself. 

2.  Classified  Groups  of  Data  Elements.  An  individual  data  element  considered  as 
transmitting  unclassified  information  may  be  viewed  together  with  other  elements  that  collectively 
transmit  information  that  is  classified.  For  example,  access  to  an  individual's  skills,  the 
capabilities  of  a  piece  of  equipment,  and  the  planned  location  of  a  unit  may  not  in  and  of 
themselves  be  classified.  But  the  fact  that  a  set  of  people  with  particular  skills,  and  or  equipment 
with  particular  capabilities  are  destined  for  a  unit  at  a  particular  location  may  compromise  military 
intentions,  or  die  Department's  knowledge  of  enemy  intentions.  To  support  data  security 
administration  and  management,  data  element  collections  which  transmit  classified  information 
should  be  cataloged,  and  an  appropriate  security  classification  should  be  assigned  as  an  attribute  of 
the  group. 

3.  Classified  Value  Associations  Une  are  cases  where  groups  of  data  elements  that 
are  normally  unclassified  may  he  classified  for  specific  value  combinations.  This  happens  when  a 
management  code  for  a  classified  program  is  explicitly  as«/v»iaa»d  with 
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Classified  Data  Elements 


Individually  the  data  element  carries 
rlactififtri  information. 


Operation  Plm 
Number 

Operation  Description 

Classified  Value  l 
Classified Value  2 
Classified  Value  3 

Unclassified  Value  1 
Unclassified  Value  2 
Unclassified  Value  3 
•  •  • 

Classified  Groups  of  Data  Elements 

Groups  of  data  elements  comprised  of 
members  which  when  taken  individually 
are  unclassified,  but  collectively  carry 
classified  information. 


Classified  Value  Associations 

Groups  of  data  elements  that  are  normally 
unclassified,  but  become  classified  for 
specific  combinations  of  values. 


Unit  Identification  >.  TvpVynifiit 
'Code '  Station  Code  ■ 

Unclassified  Valuel  "Undnadfied  Value  1 
Unclassified  Value  2  Unclassified  Value  2 
Unclassified  Vahie  3  Unclassified  Value  3 


Classified  Value  Combination 


Unit  Identification  Program  Management 

Code  Structure  Code 

Unclassified  Value  1  Unclassified  Value  1 


Unclassified  Value  3  Unclassified  Value  3 
Unclassified  Value  4  Unclassified  Value  4 


Classified  Value  Combination- 


Flgure  C-l  Example  Classified  Data  Element  Groups 
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a  specific  unit  These  types  of  data  element  collections  should  be  cataloged  along  with  die 
appropriate  security  classification  for  die  classified  value  sets,  and  the  values  which  determine  the 
security  classification  of  die  group  (e.g.,  Program  Management  Structure  Code  in  above  example) 
should  be  documented. 


C.  DOCUMENTATION  OF  THE  CLASSIFIED  COMBINATIONS 

1.  figure  C-2  depicts  how  the  relational  model  proposed  for  associating  composite 
and  derived  elements  presented  in  figures  2-10  and  3-5  can  be  used  to  document  the  classified 
groups  of  data  elements. 

2.  From  die  perspective  of  this  model,  classified  groups  of  data  elements  are  viewed 
as  a  type  of  data  element  association.  Classified  groups  of  data'  is  identified  as  a  type  of 
association  (Le.,  'SCRTY')  in  the  Association  Type  entity.  The  Association  Attribute  entity 
identifies  four  attributes  to  be  recorded  for  each  instance  of  a  classified  group  of  data: 

a.  Security  Classification  Code  (associate  levett.  The  level  of  restriction  far 
information  transmitted  by  the  data  element  group(e.g.,  C  =  classified,  S  =  secret,  TS  =  top- 
secret). 


b.  Interruption  Risk  Level  Name  (associate  levelY  The  impart  nf  i^ytinn 
or  unavailability  of  data  to  mission  accomplishment  (e.g.,  serious  =  unacceptable,  vital  =  tolerated 
for  <  3  days,  tolerable  =  tolerated  for  3  to  8  days,  nonessential  =  tolerated  far  >  8  days). 

C.  Disclosure  Risk  Name  (associate  lcvciV  The  impact  of  disclosure 
information  to  adversaries  (e.g.,  high  =  irreparable  harm,  medium  =  consequential  harm,  low  = 
embarrassment/prejudicial  harm). 

d.  Security  Class  Setting  Domain  Value  (member  levelV  The  value  frir  . 
specific  element  that,  when  viewed  in  combination  with  values  provided  by  other  elements  in  the 
group,  determines  the  security  classification  of  information  provided  by  die  group  of  elements. 
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3  •  Bsch  of  the  data  elements  participating  in  a  classified  group  of  data  elements  are 

documented  in  the  Data  Element  entity,  and  related  through  the  Association  Member  entity. 

4.  Each  classified  group  of  data  elements  is  identified  in  the  Association  entity,  and 
related  to  participating  elements  through  die  Association  Member  entity.  For  example,  the  Unit 
Deployment  Classified  Data  Group'  is  assigned  an  Association  Code  of  '811'.  This  code  identifies 
two  elements  involved  in  the  group  within  the  Association  Member  entity  (Le.,  Unit  T/frimfiratinn 
Code,  and  Deployment  Station  Code).  Each  association  inning 

a.  One  primary  or  dominant  element  (Element  Role  Code  =  'F). 

b.  One  or  multiple  secondary  or  subordinate  elements  (Element  Role  Code* 

’S'). 


5.  The  Unit  Program  Management  Classified  Value  Associations  (Association  '812') 

document  which  values  of  the  Program  Management  Structure  Code  (e.g..  Program  Value  1, 
Program  Value  2,  and  Program  Value  3)  determine  the  classification  of  die  group. 
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2.  AGENDA 

MEETING  OF  DMSO  I/DB  TASK  GROUP 
THURSDAY,  MARCH  4, 1993 

8:00 — 8:30  Overview  of  meeting  and  goals,  introductions,  DMSO  status: 

Tom  Shook,  Iris  Kameny 

UPDATE  ON  DMSO  WORKING  GROUP  AND  PROPOSAL  ACTIVITIES 

8:30 — 9:00  DMSO  Architecture  Working  Group  and  call  for  Architecture 

for  Dynamic  Scalability:  Cy  Ardoin 
9:00 — 9:30  DMSO  Environment  Working  Group  and  call  for 

Environmental  Representation:  Paul  Birkel 
9:30 — 10:00  DMSO  I/DB  Task  Group  and  call  for  Complex  Data  and 
Common  Tools:  Iris  Kameny 
10:00—10:30  Break 
10:30 — 11:00  Questions  and  discussion 

11:00 — 11:30  Update  on  DMSO  Information  System:  Cy  Ardoin 
11:30 — 12:00  Update  on  DMSO  database  directory  IDEF1X  model:  Iris 
Kameny 

12:00 —  1:00  Lunch 

UPDATE  ON  DATA  ADMINISTRATION  AND  STANDARDIZATION  EFFORTS 

1:00 — 1:30  Update  on  NIST  standards  for  IDEF  and  IRDS:  Bruce  Rosen 

1:30 — 2:00  DISA/CIM:  update  on  DoD  CIM  data  administration,  policy, 

procedures,  modeling,  etc.:  Bob  Molter 
2:00 — 2:30  JIEO  Center  for  Standards:  update  on  FDAd  C2  activities 

and  support  for  Modeling  and  Simulation:  Dunham 
2:30 — 3:00  Questions  and  discussion 

3:00 — 3:30  Break 

REPORTS  ON  PROJECTS,  STANDARDS,  W&C,  ETC.  ACTIVITIES 

3:30 — 4:30  Report  on  Close  Combat  Tactical  Trainer  (CCTT)  project  data 

activities:  Rob  Wright 

FRIDAY,  MARCH  5, 1993 

CONTINUATION  OF  REPORTS  ON  PROJECTS,  STANDARDS,  W&C,  ETC. 

ACTIVITIES 

8:00 —  8:30  Update  on  Joint  Data  Base  Element  (JDBE)  project 
activities:  Peter  Valentine 

Lessons  learned  from  JDBE  IDEF1X  classes:  led  by  John 
McDonnell 


8:30—  9:00 
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9:00 —  9:30  Brief  and  demo  of  Army  M&S  Catalog:  Darlene  Pittenger  and 

Wanda  Wharton 

9:30 — 10:00  Report  on  TRAC  Automated  Data  System  (TADS)  data 

activities:  Howard  Haeker 

10:00 — 10:15  Report  on  Army  Modeling  and  Simulation  Executive  Council 

(AMSEC)  Subcommittee  on  Data:  Erwin  Atzinger 
10:15—10:45  Break 

10:45 — 11:15  Report  on  data  standards  activities:  Iris  Kameny 

11:15 — 11:45  Report  on  new  DARPA  BAAs  in  the  data  area:  Gio 

Wiederhold 

11:45 — 12:15  Status  of  Navy  Verification,  Validation,  and  Accreditation 

(W&A)  Processes:  Simone  Youngblood 
12:15 —  1:15  Lunch 

1:15 —  1:30  Report  on  (SDIO)  Analytic  Tool  Box:  Anne  Marie  Gnacek 

1:30 —  2:10  Briefing  for  Strategic  Planning  for  DoD  intelligence  Data 

Administration:  Linda  Calvert 

2:10 —  2:30  Discussion 

2:30 —  3:00  TECNET  brief  and  demonstration:  George  Hurlburt 

3:00 —  3:30  Break 

BRIEFS  AND  DISCUSSION  OF  GEO-SPATIAL  DATA 

3:30 —  4:30  DMA  brief  on  Geo-Spatial  Information  to  include  new 

available  products  and  prototypes  (e.g.,  Digital  Chart  of  the 
World),  terrain  data  models,  DMSO  Project  205A,  and 
products  of  the  future,  and  JCS  MOP  31:  Dave  Danko  and 
Bob  Jacober 

4:30 —  5:00  Discussion  of  geo-spatial  information  needs,  standards,  etc.: 

led  by  Paul  Birkel 


3.  LIST  OF  ATTENDEES 

Tom  Adrian,  CACI-USA 

Cy  Ardoin,  IDA  (703)  845-6647  ardoin@ida.org 

Erwin  Atzinger,  USA/AMSAA  (410)  278-65'76  erwin@brl.mil 

James  Augins,  Navy  (619)  553-6085  augins@nosc.mil 

Robyn  Benensohn,  SAIC  619-546-6231  robyn@jupiter.saic.com 

Paul  Birkel,  MITRE  (703)  883-6399  pbirkel@mitre.org 

Bob  Bishop,  DTIC-AP  (703)  274-7662,1,  rbishop@dgis.dtic.dla.mil 

William  Burch,  Navy  burch@nosc.mil 

Linda  Calvert,  MITRE  703-883-6326  calvert@mitre.org  Wallace 

Chandler,  USA/CAA,  (301)  295-1652 

Bill  Clydesdale,  SPAWAR  (703)  602-5696 

Deborah  Cooper,  Paramax  703-620-7778  cooper@rtc.reston. 

paramax.com 
(408) 655-0400  x  4248 


Martin  Costellic,  DITRA 
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Willie  Cowan,  BDM  (NASA)  (202)  479-5293  fax  (202)  863-8407 

David  Danko,  DMA  (703)  487-8151 

Tina  De  Angelis  AF/SDIO  310-363-3253  fax:  310-363-1753  Charlie 

Dunham,  JIEO  (703)  487-8340 

CDR  Jim  Etro,  CNO,  202-653-1616 

COL  Ed  Fitzsimmons,  DMSO  (703)  998-0660  fitzsim@charm.isi.edu 

Anne-Marie  Gnacek,  NRC,  SDIO/GMN 

Peggy  Gravitz,  Adv  Res  Cen  (205)  922-1512  x2170 

John  Griffiths,  Intel.  Community  M&S  Coordinating  Group  703-820-2841 

Lucy  Haddad,  Resource  Consultants  Inc.,  (CCTT)  (407)  282-1451 

Howard  Haeker,  USA/TRAC  (913)684-3030  haekerh@tracer.army.mil 

Becky  Harris,  CIM/XF  (703)  285-5381  harrisb%cimtys%cim 

©cimgate. disacim.osd.mil 

Dan  Hogg,  JCS/J8  (703)  697-8899 

Chien  Huo,  JIEO  (703)  487-8046  huoc@cc.ims.disa.mil  George 

Hurlburt,  NavAirWarCen  hurlbxnt@technetl.JCTE.JCS.mil 

CDR  Rick  Huska,  (AFMSC)  SDIO/GMN 
Bob  Jacober,  DMA  (presented  with  Dave  Danko) 

Iris  Kameny,  RAND  (310)393-0411  kameny@rand.org 

Kenneth  Kaufmann,  NCCOSC  (619)  553-6098  kaufmann@nosc.mil 

Tom  Kurihara,  DISA  Studies  (203)  318-1074  x311 
Steve  Lawyer,  IDA  (703)  845-6696  lawyer@ida.org 

Mike  Ligtner  JMASS  (513)476-4464  fax  513— 476-4746 

Mike  Lilienthal,  DMSO  (703)  998-0660  mlilient@dgis.dtic.dla.mil 

Ernie  Lucier,  NASA/SED  (202)  358-0772  nhqvax.hq.nasa.gov 

Gary  Mayes,  SSDC  (205)  955-4904 

John  McDonnell  USA/EPG  (huachuca) 

Lana  McGlynn,  USA/MSMO  (703)  607-3335 
Ronald  Merriman,  Army/ODISC4 
Grant  Miller  NASA  EOSDIS  Program 

Bob  Molter,  DDI/CIM  (703)  746-7926  rmolter@ddi.c3i.osd.mil 

Jack  Nicklas,  RCI  (703)  893-6120 

William  P.  Pala,  NRL  pala%sunburst.nrl.navy.mil 

Darlene  Pittenger,  USAT  TSMO  (703)  607-3419  fax  (703)  607-3381 
Clay  Putnam,  GPS  Technology  (703)  271-1700 

Lauri  Rohn,  OSD  (PA&E)  (703)  695-1681  rohnll@scpael, pae.osd.mil 

Bruce  Rosen,  NIST  (301)  975-3246  rosen@ecf.ncsl.nist.gov 

C.  Roswell,  HQ/DMA 

Mike  Sarkovitz,  PMA  205  Code  1D1  (703)  692-2641  x  3006 

Richard  Schiller,  mwvm.mitre.org 

Roberta  Schoen,  DTIC  (703)  274-5367  rschoen@dgis.dtic.dla.mil 

Steve  Shervais,  CACI AFSAA  (703)  875-2911 

Maj  Tom  Shook,  DMSO  (703)  998-0660  tshook@dgis.dtic.dla.mil 

Bob  Sutter,  Argonne  Lab  (202)  488-2427  sutter@anl.gov 

Peter  Valentine,  USA/EPG  (602)  538-4976  valentin@huachuca-emh  1 7 . 

army.mil 

(703)  602-4540  weatherj@smtp-gw.spawar. 

navy.mil 


Jim  Weatherly,  Navy 
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Ron  Weller,  SAIC,  Arlington 

Wanda  Wharton,  USA/MSMO  (703)607-3383  fax  703-607-3381 

Gio  Wiederhold,  DARPA/SISTO  (703)696-2218  gio@darpa.mil 

Ken  Wimmer,  SAIC/DMSO  (703)  379-3770  kwimmer@dgis.dtic.dla.mil 

Joyce  Wineland,  Navy  Intel  Cmd  (301)  763-1390 

Rob  Wright,  RCI  (407)  282-1451 

Simone  Youngblood,  John  Hopkins  U/APL  (301)  953-5000  x4000 

simone@aplcomm.jhuapl.edu 

4.  SUMMARY  OF  ISSUES,  WORK-TO-DO,  TOPICS  FOR  NEXT 
MEETING 

(1)  Most  significant  happenings  between  the  two  I/DB  meetings  were:  the 
new  DoD  Enterprise  Model  seems  to  allow  bottom-up  data  modeling  and 
definition  of  entities  and  data  element  standards  (need  to  find  out  more  at 
the  March  22nd  meeting),  and  DISA/CIM  will  now  support  composite  and 
derived  data  entities  in  addition  to  atomic  data  elements  in  the  DDRS.  If  all 
this  is  true,  then  Iris  and  Twyla  need  to  work  with  the  DMSO  to  begin  to 
develop  data  administration  procedures  and/or  guidelines  conformant  with 
the  new  DoD  Enterprise  Model. 

(2)  Iris  organize  special  working  group  session:  classified  workshop  on 
intelligence  data 

(3)  Ken  Wimmer  obtain  documents: 

—  Update  on  8320.  l.M 

—  Get  copy  of  John  Keene’s  Technical  Architecture  for  Information 
Management 

(4)  With  respect  to  signup  lists  at  workshop: 

a.  Iris:  Put  together  I/DB  Task  Group  members  interests.  First 
circulate  as  file  and  then  make  into  database  to  enter  under  I/DB 
bulletin  board. 

b.  Ken  Wimmer:  be  sure  names  from  signup  sheet  for  DIS  Conference 
Information  get  on  DIS  mailing  list. 

c.  Ken  Wimmer/Iris  Kameny:  be  sure  people  signing  for  DoD  TRM 
and/or  NIST  APP  get  documents. 

d.  Ken  Wimmer:  be  sure  people  signing  up  for  DSB  Summer  Study 
report  on  M&S,  get  document. 

(5)  Iris/Steph  work  with  Cy  and  Ken  to  populate  I/DB  bulletin  so  that  soon 
I/DB  users  can  begin  accessing  it. 

(6)  Iris/Steph,  organize  task  groups  for  study  of  complex  data  and  data  W&C 
d)  Topics  for  next  meeting: 

—  Brief  from  Navy  on  oceanography  and  atmospheric  data  standards. 

—  Brief  from  NASA  librarian  on  EOS  databases  that  are  available  for 
use. 

—  Brief  on  DIS  and  PDUs  towards  understanding  how  data 
standardization  affects/works  with  the  DIS  world. 
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—  Brief  on  X3L8,  the  committee  on  data  representation  standards, 
regarding:  framework  for  generation  and  standardization  of  data 
elements,  classification  of  concepts  for  identification  of  domains, 
basic  attributes  of  data  elements,  registration  and  naming 
principles  for  data  elements. 

—  Brief  on  how  DMA  relational  standards  relate  and  map  to/from 
USGS  object  standards. 

—  Brief  update  on  DoD  Enterprise  Model 

5.  UPDATE  OF  DMSO  WORKING  GROUP  AND  PROPOSAL 
ACTIVITIES 

This  set  of  briefings  provided  an  update  on  what  was  happening  with  DMSO 
FY93  proposals  and  to  make  more  explicit  the  kinds  of  efforts  DMSO  is 
interested  in  with  respect  to  the  upcoming  call  for  FY94. 

(1)  DMSO  Architecture  Working  Group  and  call  for  Architecture  for 
Dynamic  Scalability:  Cy  Ardoin 

Scalability  is  the  ability  to  accommodate  large,  dynamic  changes  in  size  and 
complexity  within  models  and  simulation  systems.  It  can  be  characterized  as 
having  the  following  dimensions: 

—  Cardinality:  number  of  objects  in  the  simulation 
—  Granularity:  fidelity  and  level  of  detail  of  objects  and  environment 
—  Heterogeneity:  diversity  of  objects  and  environment 
—  Variability:  cardinality  and  granularity  may  differ  over  time  and  by 
node 

There  are  three  generally  accepted  classes  of  simulation:  (1)  constructive 
(computer  models),  (2)  virtual  (distributed  interactive  weapon  system 
simulation),  and  (3)  live  (instrumented  tests  and  exercises).  The  call  is  for 
architectural  projects  addressing  either  of  these  three  classes  of  simulation  or 
an  architecture  for  coupling  simulation  classes  (constructive,  virtual  and 
live). 

Forty-nine  proposals  were  received  in  this  area  and  each  was  reviewed  by  five 
reviewers. 

(2)  DMSO  Environment  Working  Group  and  call  for  Environmental 
Representation:  Paul  Birkel 

The  synthetic  environment  for  use  in  M&S  includes  terrain  data,  bathymetry 
data,  meteorology,  and  atmosphere  and  near-earth  space  information.  This 
area  also  includes  methods  for  handling  changes  to  the  synthetic  electronic 
environment  based  on  both  natural  and  man-made  disturbances  as  well  as 
well  as  electromagnetic  propagation  effects. 

There  were  three  focuses  to  the  call:  (1)  Tri-service  data  and  model  standards 
development  for  atmospheric  and  oceanic  data  and  transfer  formats,  (2) 
Improved  production  development  of  synthetic  environment  data;  and  (3) 
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Methods  for  handling  dynamic  changes — effects  of  natural  and  man-made 
disturbances  that  need  to  be  reflected  in  the  underlying  environmental  data. 

Thirty-six  proposals  were  submitted  in  this  area,  most  addressing  standards 
and  DIS,  a  few  addressed  the  creation  of  a  realistic  environment.  There  were 
many  joint  proposals  across  services  and  labs  but  most  were  lacking  a  well 
integrated  management  plan.  There  were  some  good  proposals  addressing 
dynamics  but  most  were  laboratory  based  technology — perhaps  this  work  is 
not  ready  for  the  M&S  community  yet.  Many  of  the  proposals  overlapped  the 
scalable  architecture  area.  The  technical  review  team  rated  each  proposal 
with  respect  to  how  well  it  addressed  at  least  one  of  the  three  areas  and  how 
well  it  addressed  the  needs  of  the  M&S  community.  Some  of  the  proposals 
were  to  build  a  prototype  to  see  if  a  problem  could  be  solved  and  did  not 
address  standards  for  exchange.  Most  were  not  concerned  with  getting  the 
community  to  agree  on  a  standard  but  rather  were  trying  to  promote  their 
service’s  model  onto  the  community. 

Paul  mentioned  the  DMSO  desire  to  create  a  mentoring  team  to  work  with 
the  groups  winning  awards  and  several  questions  were  later  asked  (and  not 
answered)  about  the  specifics  of  this. 

(3)  DMSO  I/DB  Task  Group  and  call  for  Complex  Data  and  Common 
Tools:  Iris  Kameny 

The  60  proposals  in  this  area  were  reviewed  by  a  team  of  8  people  mainly 
members  of  the  I/DB  group.  There  were  so  many  proposals  because  many 
submitters  checked  off  data  and  tools  as  a  secondary  area.  On  a  whole,  the 
proposals  were  disappointing  since  most  of  them  failed  to  address  the  areas 
described  in  the  call.  Iris  went  over  the  call  areas  again  to  familiarize  people 
with  the  problems  and  to  encourage  people  who  are  interested  in  addressing 
one  of  the  problem  areas  or  know  of  someone  else  who  is,  to  call  her  or  the 
DMSO  office  for  copies  of  the  FY94  call  once  it  is  available.  We  believe  we 
need  a  better  way  to  reach  the  people  who  are  working  these  problems. 

The  areas  specifically  written  up  in  the  call  were: 

Complex  data:  develop  metadata  extensions  or  new  concepts  of  “standard 
data  element”  for  complex  data  types  compatible  with  CIM  if  possible. 
Design/develop  tools/techniques  for  management  of  complex  data 
repositories. 

Develop  standards  for  nomenclature  (e.g.,  aircraft  type  names)  and 
symbology  (e.g.,  graphics  icons). 

Develop  approaches  and  methodology  for  verification,  validation,  and 
certification  of  data. 

Develop  approaches  to  capture  and  manage  historical  data  (e.g.,  simulation 
data). 

Develop  classification  and  typing  taxonomies  to  support  search  across 
repositories. 

Define/develop  mechanisms  for  interchanging  data  (including  complex  data) 
across  repositories 
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Develop  an  approach  to  the  data  aggregation  security  issue  and  the  policy 
and  procedures  to  support  finding  information  across  classified  and 
unclassified  directories  and  dictionaries. 

(4)  Welcome  and  overview:  Tom  Shook 

Data  and  database  development  is  a  very  technical  and  painful  process.  Both 
fall  into  the  M&S  infrastructure  area  since  distributed  interactive  simulation 
requires  the  sharing  and  exchange  of  data  which  in  turn  requires  a  strong 
foundation  embodying  data  standards.  The  goals  and  objectives  of 
DISA/JIEO  are  to  give  the  user  on  defense  networks  the  best  technology 
possible  and  are  consistent  with  DMSO  communication  and  data  objectives. 
We  need  to  work  out  the  details  of  execution  and  share  common  problem 
solutions  across  organizations.  We  need  to  move  forward  by  bringing  the 
community  ahead... which  is  not  an  easy  thing  to  do. 

Tom  sees  a  bright  future  for  DMSO  within  the  new  administration  and  the 
DMSO  has  been  busy  educating  the  new  people  as  to  the  DMSO  goals  and  the 
issues.  DMSO  needs  to  help  in  the  development  of  working  level  standards  to 
promote  interoperability.  This  needs  to  be  accomplished  by  building 
consensus,  which  is  a  difficult  task.  DMSO  is  committed  to  working  with  the 
JIEO/Center  For  Standards  (CFS),  CIM,  NIST,  etc.  We  are  working  toward  a 
future  when  MILSTDs  are  a  thing  of  the  past.  Some  of  the  technology  needed 
by  the  M&S  community  will  not  be  furnished  by  commercial  products  and 
developments.  The  M&S  community  needs  to  make  its  needs  known  to  the 
commercial  world  so  that  they  are  more  likely  to  be  met  in  standards  and 
products.  CFS  is  playing  a  unique  role  in  pulling  together  DoD  needs  so  they 
can  be  heard  as  a  single  voice.  An  important  I/DB  task  group  role  is  to  help 
DMSO  re-vector  for  the  future. 

The  M&S  community  has  to  play  at  the  realtime  C3I  level.  There  is  wide 
acceptance  now  of  what  DMSO  is  trying  to  do.  The  DSB  summer  study 
report  on  M&S  has  just  been  signed  off  and  people  can  sign  up  to  request 
copies  (a  sign-up  sheet  was  made  available  at  the  workshop  and  will  be 
handled  by  Ken  Wimmer  in  the  DMSO).  Copies  should  be  available  by  March 
16  and  draft  versions  may  be  available  now  through  the  Public  Affairs  Office 
or  DDR&E. 

A  Distributed  Interactive  Simulation  (DIS)  workshop  is  held  every  six 
months  and  the  next  one  is  in  Orlando  March  22-25.  DIS  has  been  accepted 
as  an  IEEE  standard  for  using  WANs  for  intercommunication.  It  is  non¬ 
proprietary  (as  are  all  standards)  and  examples  of  its  use  for  interoperability 
were  demonstrated  at  the  last  DIS  workshop  with  different  contractors 
connecting  individually  developed  simulations.  The  DIS  1.0  protocols  have 
been  defined  but  help  is  needed  with  later  (2.0... 7.0)  sets  of  protocols. 

The  DMSO  FY94  call  for  proposals  will  be  coming  out  soon.  People  can  check 
with  Gary  Bridgewater  or  Ken  Wimmer  (at  (703)  379-3770  or  by  email: 
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kwimmer@dgis.dtic.dla.mil  and  gbridgew@dgis.dtic.dla.mil)  to  find  out  the 
date. 

(5)  Update  on  M&S  Information  System:  Cy  Ardoin 

The  M&S  IS  goal  is  to  provide  an  information  resource  center  that  will  help 
members  of  the  community  in  locating,  retrieving  and  communicating 
information  in  a  distributed  environment.  It  is  based  on  commercial 
standards  and  tools  that  include  Archie  (provides  string  search  on  file 
names),  Wide  Area  Information  System  (WAIS)  provides  string  search  on  the 
contents  of  files,  gopher  (access  to  bulletin  systems),  and  telnet.  Types  of 
data  provided  include:  general  information  about  M&S,  database  and  M&S 
catalogs  for  M&S  developers  and  users,  general  information  for  community 
(POCs,  organizations,  calendar,  glossary),  online  help,  e-mail,  world  wide 
bulletins,  and  local  bulletins  and  file  space.  The  I/DB  Task  Group  will  be  the 
first  user  of  the  bulletin  board  support  for  an  M&S  special  interest  group. 

The  I/DB  bulletin  board  will  include  access  to:  glossary,  document  references, 
published  meeting  notes,  I/DB  objective,  database  of  I/DB  members  and  their 
areas  of  interest,  list  of  ongoing  projects  in  the  M&S  and  data  areas,  minutes 
for  review  from  the  last  meeting,  etc.  (People  were  asked  to  give  Iris  a  list  or 
paragraph  describing  their  interests  and  she  will  begin  to  compile  these, 
possibly  into  a  database  that  includes  other  general  information  such  as 
organization,  phone,  email,  address). 

Issues  include:  need  to  decide  on  a  standard  WP  format,  delay  in  getting  the 
Oracle  server  at  DTIC,  and  security  (see  later  brief  on  TECNET). 

It  was  mentioned  that  there  is  a  Defense  Information  Systems  Security 
Program  (DISSP)  and  that  Barbara  Kirsch  (703-487-8252)  at  JIEO  was  a 
POC.  Roberta  Schoen  (DTIC)  furnished  the  following  information  after  the 
meeting:  DISSP  is  doing  central  guidelines  for  DoD  security,  contact  point  is 
Lt.  Col.  Joe  Jaremko  at  (703)  696-1904.  They  have  soup  to  nuts  consulting 
on  security,  but  are  VERY  understaffed  right  now.  Their  Divisions  are 
Accreditation,  Architecture  and  Engineering,  INFOSEC  Products,  INFOSEC 
Professionalization,  and  INFOSEC  Countermeasures.  Lt  Col.  Jaremko  is 
head  of  Architecture  and  Engineering  and  oversees  several  task  groups, 
including  the  one  on  security  guidelines,  and  on  security  of  DISN  (MILNET). 

By  the  end  of  March,  the  M&S  IS  will  be  asking  for  volunteer  users.  Users 
will  be  limited  to  government  and  government  supported  contractors.  The 
number  and  makeup  of  the  volunteer  users  testing  the  system  will  be 
controlled  until  the  system  is  operational  at  DTIC  and  running  reliably. 

(6)  Update  on  DMSO  database  directory  IDEF1X  model:  Iris  Kameny 

Work  done  by  Kameny  and  Valentine  (JDBE  project)  on  developing  an 
IDEF1X  model  for  the  database  directory  from  the  E-R  model  was  presented. 
Iris  presented  IDEF1X  modeling  observations  made  during  her  initial 
exposure  to  the  methodology.  She  believes  tools  are  needed  to  support  the 
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capture  and  automated  use  of  business  rules:  to  add  in  clarification  when 
models  become  more  complicated,  to  capture  differences  in  model  views  as 
different  groups  concur  on  a  single  model  (such  as  cardinality  differences), 
some  people  may  relate  better  to  textual  business  rules  than  to  graphics,  and 
machine  processing  of  such  rules  could  be  used  to  detect  inconsistencies. 

Also,  the  graphics  can  become  unwieldy  when  M-N  relationships  require  the 
creation  of  associative  entities  and  generating  informative  arc  labels  for  these 
is  difficult.  Also,  multiple  relationships  between  two  entities  may  be  difficult 
to  understand  in  terms  of  the  appropriate  attributes.  As  we  build  bottom-up 
models,  we  need  to  use  naming  conventions  that  are  as  consistent  as  possible 
with  CIM. 

Pete  Valentine  will  be  generating  the  Oracle  database  schema  for  the  DMSO 
database  directory,  and  he  will  prepare  a  short  writeup  addressing  the 
interfaces  needed.  Other  issues  include:  need  to  develop  a  key  word 
taxonomy  to  support  searches,  need  to  decide  how  the  directory  will  be 
populated,  and  there  may  be  a  need  for  further  collaboration  with  others 
needing  a  database  directory.  With  respect  to  the  latter,  we  should 
coordinate  with  George  Hurlburt  on  TECNET  catalog  for  T&E  databases.  A 
copy  of  the  IDEF1X  briefing  and  model  was  left  with  Beckie  Harris  at 
DISA/CIM. 

6.  UPDATE  ON  DATA  ADMINISTRATION  AND  STANDARDIZATION 
EFFORTS 

(7)  Update  on  NIST  standards  for  IDEF  and  IRDS:  Bruce  Rosen 

Bruce  began  by  updating  the  group  on  the  IRDS  FIPS  156  standard.  It  is 
coming  to  the  end  of  its  5  year  review  cycle  and  they  expect  the  ANSI  X3H4 
group  to  renew  it  as  a  standard.  The  IRDS  export/import  ANSI  standard 
X3. 195-1991  is  now  under  review  at  NIST  to  be  made  into  a  FIPS.  It  will  be 
an  exchange  standard  for  data  between  IRDSs  and/or  other  tools.  The 
services  interface  to  IRDS  has  also  been  published  as  an  ANSI  standard 
X3. 185-1992,  but  NIST  does  not  plan  to  make  this  into  a  FIPS.  He  discussed 
the  differences  between  the  IRDS  ANSI  X3H4  standard  and  the  international 
(ISO  IS10728)  IRDS  standard.  The  ISO  standard  is  more  like  the  ANSI 
services  standard  but  based  on  a  different  model.  The  ISO  IRDS  interface  is 
based  on  a  relational  concept  and  is  a  software  to  software  interface  and  does 
not  address  the  human  interface.  The  ANSI  standard  is  based  on  a  model  of 
exchange  at  the  human  interface  level  and  the  screen  interface  level.  The 
ANSI  services  interface  standard  describes  exchange  at  the  software-to- 
software  level  based  on  the  ANSI  human  interface.  Both  ANSI  and  ISO  have 
services  level  interfaces  but  they  are  incompatible,  i.e.,  cannot  be  mapped  to 
each  other. 

The  X3H4  is  working  with  the  ISO  IRDS  rapporteur  group  on  the  next 
version  of  an  IRDS  standard,  IRDS+  (which  is  not  as  inclusive  as  the  future 
IRDS2  standard  described  in  the  briefing  I/DB  received  in  June  92).  This 


977 


would  be  a  services  interface  standard  not  a  human  interface  standard. 

X3H4  has  submitted  a  large  number  of  changes  to  the  ISO  IRDS  group  to  try 
to  get  the  ISO  standard  to  incorporate  US  needs.  The  US  is  saying  that  the 
future  lies  in  cooperating  in  the  development  of  an  international  standard 
and  this  is  where  they  want  to  go  with  IRDS2.  If  things  go  well,  by  June 
there  may  be  a  first  draft  of  one  unified  IRDS+  international  standard. 

Question  about  what  effect  one  unified  ISO  standard  would  have  on  ANSI 
IRDS  standard?  Answer  is  that  it  probably  would  not  affect  the  renewing  of 
IRDS1,  and  since  the  ISO  standard  wouldn’t  address  the  human  interface, 
the  ANSI  could  try  to  map  the  human  interface  onto  the  ISO  services 
interface. 

A  question  was  asked  about  PCTE  (Portable  Common  Tool  Environment) 
provided  by  the  European  Computer  Manufacturers  Association  (ECMA), 
standard  ECMA  149,  and  its  relation  to  IRDS.  The  purpose  of  PCTE  is  to 
enable  software  tools  to  work  together  through  definition  of  a  common 
environment.  Some  think  this  just  involves  a  common  repository,  others  a 
dictionary.  The  old  dictionary  concept  was  based  on  a  fixed  metadata 
schema,  the  new  dictionary  concept  supports  describing  the  structures 
needed  such  as  databases,  resource  assets,  etc.,  in  content  modules.  For 
purposes  of  the  new  dictionary,  the  metadata  descriptions  of  structures  are 
called  content  modules  and  the  word  “schema”  is  reserved  for  referring  to 
database  structures.  In  the  new  dictionary,  there  would  be  multiple  content 
modules  describing  the  structure  of  the  objects  in  the  repository.  However, 
the  PCTE  people  are  not  coordinating  their  effort  with  the  IRDS  groups. 

Question  about  object-oriented  SQL:  people  are  currently  working  on  SQL3  to 
provide  a  standard  language  for  object  oriented  DBMSs.  It  will  be  a  large 
standard  and  will  be  issued  in  the  95-96  timeframe.  (Bruce  noted  how  large 
and  complex  the  standards  were  getting:  IRDS  is  about  700  pages  long  and 
PCTE  around  400  pages).  CORBA  is  an  object-oriented  standard  that  has 
come  from  the  Object  Management  Group  (OMG)  consortia.  Future  IRDS 
versions  will  be  oriented  toward  supporting  an  object-oriented  machine.  The 
most  impoxtant  thing  for  IRDS  would  be  to  unite  the  ANSI  and  ISO 
standards  into  one  standard.  There  is  a  question  about  whether  they  will  be 
able  to  define  a  common  data  object;  it  is  conceivable  that  there  may  be 
different  standards  for  different  views. 

Bruce  next  discussed  IDEF  standards.  He  announced  that  IDEF  is  now  an 
acronym  for  “Integration  Definition  Language”.  NIST  developed  the  criteria 
for  evaluating  modeling  methodology  based  on  non-proprietary  information 
engineering.  Criteria  for  standards  usually  come  from  a  standards  body  that 
is  composed  of  experts  from  government,  academia,  and  commerce  but  the 
IDEF  users  group  was  different.  Their  charter  did  not  include  voting 
procedures  and  they  tended  to  be  more  of  a  discussion  group.  Based  on  input 
from  that  group  the  draft  IDEF1X  FIPS  contains  two  parts,  a  formative  part 
(defining  the  standard)  and  an  informative  part  (on  how  the  standard  should 
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be  used).  By  March  15th,  NIST  expects  to  receive  consolidated  comments 
from  the  IDEF1X  users  group  that  will  clean  up  the  draft  and  comments  from 
DoD.  They  will  then  have  30  days  to  respond  to  comments,  and  will  then 
finalize  and  publish  the  document.  The  document  does  not  have  to  go 
through  another  round  of  review.  An  IDEF1X  subgroup  developed  a  formal 
mathematical  logical  description  of  the  standard  and  forwarded  that  version 
to  the  IDEF  senior  committee.  NIST  will  probably  put  this  into  the 
informative  section  because  it  has  not  been  formally  reviewed  and  it  seemed 
that  it  was  too  difficult  for  many  people  to  read  and  understand.  The  IDEF 
FIPS  may  be  the  first  to  go  to  Mr.  Brown,  the  new  Secretary  of  Commerce. 

(8)  DISA/CIM:  update  on  DoD  CIM  data  administration,  policy, 
procedures,  modeling,  etc.:  Bob  Molter 

Bob  went  over  the  implementation  status  of  the  data  administration  areas: 
policy,  standards,  infrastructure,  procedures,  tools,  training,  and 
miscellaneous  (data  administration  strategic  plan,  FY93  planning  guidance, 
data  migration  and  reverse  engineering  and  data  migration  and 
implementation  planning).  High  points:  8320. 1-M  is  in  informal 
coordination,  comments  were  due  Jan  20  and  it  will  be  distributed  as  a  new 
draft  at  the  Data  Administration  Council  meeting  on  March  19.  It  will  be 
aligned  with  the  new  DoD  Enterprise  Model  which  is  being  released  on 
March  22.  He  expects  it  to  go  out  for  formal  coordination,  three  weeks  after 
that  session.  8320. 1-M- 1  has  become  a  standard.  Reverse  engineering:  Aiken 
is  leading  this  effort  to  reverse  engineer  six  systems  in  the  business  area  to 
develop  and  refine  procedures  and  to  identify  tools  that  are  helpful  or  not 
helpful.  CIM  is  beginning  to  address  security  (data  aggregation  and  multi¬ 
level  security  requirements),  quality  assurance,  and  are  interested  in  “other” 
data  types  and  welcomes  support  and  good  ideas  in  this  area  from  the  I/DB 
task  group.  A  question  was  asked  about  adding  structured  data  objects  to 
Bob’s  list  and  he  brought  up  an  issue  as  to  whether  messages  and 
transactions  should  be  considered  as  data  objects  and  how  these  would  be 
packaged  as  objects. 

Bob,  then  gave  us  a  preview  of  the  DoD  Enterprise  Model  which  was 
developed  through  Bunny  Smith’s  organization  with  DDI  sponsorship.  It  is 
the  result  of  work  done  by  both  contractors  and  government  people.  It  will  be 
presented  in  a  3—4  hour  session  at  George  Mason  University  on  March  22  and 
again  at  the  FIM/TIM  conference  in  Monterey  just  for  government  people 
(Melanie  Williams  703-756-4740,  41,42).  One  appendix  discusses  how  to  do 
model  integration.  Instead  of  top-down  and  bottom-up  linking  up,  it 
discusses  layering.  This  will  make  it  easier  to  integrate  policy  and  data 
models  though  there  will  probably  be  some  holes.  The  bucket  approach 
allows  one  to  start  modeling  from  the  middle-down  or  bottom-up  but  one 
would  need  to  get  with  functional  experts  first  to  be  sure  they  are  getting  the 
right  things  into  the  right  buckets.  There  may  be  a  need  to  come  in  at  the 
middle  level  and  further  sub-categorize  entities  and  decompose  their 
attributes  to  arrive  at  the  lower  level  at  which  you  want  to  model.  The 
Enterprise  Model  has  its  basis  in  the  CALS  support  for  weapon  system 
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development.  John  Keene’s  effort  to  develop  a  DoD  architecture  preceded  the 
Enterprise  Model  and  is  the  environment  the  Enterprise  Model  will  be 
implemented  in  (whatever  this  means).  There  is  a  close  fit  between  John 
Keene’s  and  the  Marine’s  architecture.  The  Enterprise  Model  document  will 
be  given  out  at  the  meeting  on  March  22  and  will  also  be  given  to  DTIC  for 
distribution.  Russ  Richards  is  in  charge  of  the  buckets  (data  side)  at  703- 
285-5378). 

(9)  JIEO  Center  for  Standards:  update  on  FDAd  C2  activities  and 
support  for  Modeling  and  Simulation:  Charlie  Dunham 

The  JIEO/DISA/CFS/Information  Directorate/C3I  Support  Division’s  mission 
is  to  achieve  a  fully  interoperable  C2  environment  through  effective  data 
standards  coordination  and  program  development.  This  includes 
management  of  and  active  participation  in  the  development  of  standards  for 
data  elements  and  data  models  for  C2  programs,  projects,  and  migrating  C2 
legacy  systems.  Thrust  areas  include:  C2  data  standards  coordination,  C2 
data  elements,  C2  data  modeling,  and  C2  functional  data  administration. 
Charlie  provides  staffing  and  support  for  Dr.  Quinn,  the  C2  FDAd.  The  last 
page  of  his  briefing  included  POCs  for  each  of  the  four  thrust  areas. 

Developing  standards  for  C2  requires  much  horizontal  coordination  since 
DoD  overall  standards  are  unknown,  there  are  multiple  uncoordinated  C2 
“architectures”,  and  there  is  conflict  among  acquisition  specific  standards.  In 
addition,  most  standards  and  specification  work  has  been  done  by 
individuals,  there  is  resistance  to  accepting  standards  of  others,  and  no  good 
mechanism  exists  for  enforcing  standards.  There  is  thus  a  real  need  to  focus 
on  standards  coordination. 

An  important  objective  (from  the  DMSO  perspective)  in  the  C2  data  elements 
program  is  the  development  of  a  C2  Data  Element  Dictionary  repository 
which  facilitates  application  requirements  and  conforms  with  the  DoD-wide 
DDRS.  They  are  looking  at  the  requirements  for  a  C2  Distributed  Dictionary 
with  coordinated  contributing  databases,  that  addresses  the  C2  user 
requirements  and  is  aligned  with  the  CIM  process.  This  needs  to  be  defined 
in  a  way  that  addresses  working  level  needs  and  has  to  have  good  links  to 
programs  and  projects.  They  need  to  develop  integrated  procedures  to 
perform  C2  data  standardization  for  the  mandated  procedures:  need  a  unified 
process  to  achieve  consensus  and  approval  for  DoD  wide  C2  data  element  and 
model  standards.  They  need  to  develop  a  uniform  process  for  technical 
coordination  of  C3  data  fora  to  facilitate  applications  development  and  life 
cycle  management.  They  need  to  coordinate  among  projects  with  different 
data  element  standards  (e.g,  MTFs,  TADILs,  IDEAS,  JOPES).  They  look  at 
DMSO  as  being  a  node  in  their  distributed  dictionary  network. 

Charlie’s  group  needs  to  provide  interim  C2  data  element  approval.  For 
example,  the  JUDI  (C4I  for  the  Warrior)  C2  interim  data  elements  are 
available  for  C2  FDAd  approval.  The  JUDI  effort  has  been  developing  SDEs 
from  the  USMTFs  by  looking  at  13  basic  message  formats.  They  also  need  to 


980 


deal  with  data  verification  and  validation,  some  data  may  be  “made-up” 
because  it  is  missing.  They  also  need  to  identify  those  areas  in  which  there  is 
no  good  source  of  data. 

As  far  as  data  modeling  goes,  they  are  validating  the  fire  support  model  for 
the  second  time,  and  are  establishing  justification  for  requiring  that  all 
entities  in  a  model  satisfy  all  three  services.  Steps  for  technical  validation 
include:  use  of  subject  matter  experts,  developing  consensus  on  IDEF1X 
model,  and  capturing  rational.  They  plan  to  integrate  the  fire  support  and 
air  operations  data  models  into  one  data  model  architecture.  They  are 
currently  testing  out  the  approval  process  for  seven  JOPES  entities. 

7.  REPORTS  ON  PROJECTS,  STANDARDS,  W&C,  ETC. 

ACTIVITIES 

(10)  Report  on  Close  Combat  Tactical  Trainer  (CCTT)  project  data 
activities:  Rob  Wright 

CCTT  will  consist  of  fully  interactive  networked  simulators  and  C3 
workstations  that  replicate  the  vehicles  and  weapon  systems  of  a  mechanized 
infantry  or  armor  company  team,  portray  supporting  combat,  combat  support, 
and  combat  service  support  elements,  and  operate  on  a  simulated  real-time 
electronic  battlefield.  It  is  a  follow-on  to  SIMNET-T  with  more  battlefield 
effects,  greater  field  of  view,  more  realistic  data  package,  open  systems 
architecture,  configuration  management,  and  higher  resolution  terrain.  The 
CCTT  data  collection  program’s  purpose  is  to  provide  CCTT  contractors  with 
certified,  accurate,  and  usable  data  in  a  timely  manner.  The  data 
requirements  categories  include:  weapon  system/equipment  characteristics, 
weapon  system/equipment  performance  characteristics,  doctrine  and  tactics, 
occupational  information,  crew/force  configuration,  and  environment.  The 
CCTT  documentation  collection  consists  of  many  varieties  of  documents 
including:  engineering  drawings,  specifications,  CM  reports,  firing  tables, 
models,  anomalies,  design  documents,  test  reports,  service  bulletins,  overhaul 
manuals,  training  circulars,  system  performance  tests,  etc.  Entries  for  these 
are  documented  in  the  DOCATs  system  which  is  moving  to  FOXPRO. 

The  CCTT  contractors  are  limited  in  combat  arms  experience  so  the  CCTT 
data  collection  activity  provides  them  with  W&Aed  relevant  and  appropriate 
data  that  will  be  consistent  across  the  various  contractors.  The  W&A 
process  includes  participants  from  various  schools  who  help  develop  data  and 
design  tests  that  can  be  used  for  verification  of  contractor  developed 
simulator  models.  The  CCTT  data  collection  effort  supports  W&A  in  that  it 
verifies  that  data  is  complete,  identifies  data  voids,  identifies  discrepancies, 
validates  that  information  is  complete,  and  certifies  that  data  is  acceptable. 

They  currently  have  databases  of  ground  systems  populated  with  tank 
platoons  and  in  future  will  have  company/teams,  battalion/task  force.  CCTT 
will  eventually  incorporate  Army  attack  helicopters  and  Black  Hawks  and 
aviation  tactical  trainers.  They  need  to  link  the  parameters  database  to  the 
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document  system.  They  will  also  be  maintaining  a  database  of  red  and  blue 
semi-automated  force  (SAFOR)  behaviors  that  will  need  to  be  linked  to  the 
documents.  Asked  about  security:  hasn’t  been  addressed  yet  but  will  be 
because  they  will  be  required  to  operate  in  a  classified  mode  and  handle 
classified  data  when  they  participate  in  the  Louisiana  Maneuvers. 

Rob  described  their  success  with  using  the  IDEFO  activity  modeling 
procedures  to  model  the  CCTT  CALS  information  flows  to  specify 
management,  data  and  information  exchange,  etc.  needed  among  the  many 
different  CCTT  players.  This  was  a  great  experience  and  showed  explicitly 
how  contractual  agreements,  CDRLs,  letters  etc.  would  flow  and  they 
strongly  recommend  its  use  for  other  projects. 

(11)  Update  on  Joint  Data  Base  Element  (JDBE)  project  activities: 
Peter  Valentine 

JDBE  staff  works  in  the  Test  and  Evaluation  Command  of  the  Army.  Their 
major  goals  are  to  standardize  definitions  of  data  elements,  and  promote 
exchange  and  sharing  of  data  between  existing  legacy  systems.  Their  current 
area  of  concentration  is  electro-magnetic  characteristics  of  equipment  which 
includes  all  emitters.  A  suggestion  was  made  that  they  focus  on  one  specific 
class  of  emitters  to  do  a  proof  of  concept  for  DMSO.  They  have  developed 
their  own  repository  to  hold  IDEF1X  models,  standard  data  elements, 
directories,  etc.  because  the  DISA/CIM  DDRS  did  not  include  storing 
anything  other  than  metadata  for  SDEs  (the  future  repository  Jeff  Wolfe’s 
people  are  working  on  will  hold  many  types  of  objects  including  data  models). 
Their  repository  will  include  a  browsing  tool  for  helping  users  find  what  they 
are  looking  for. 

Question  was  asked  as  to  who  is  involved?  and  answered  that  they  need  to 
get  more  people  involved  (in  the  Army  at  least  AMSAA  and  TRAC)  and  that 
they  need  to  work  through  CDAds  and  FDAds  to  be  sure  they  have 
participants  representing  the  service  and  functional  area  preferred 
databases. 

NOTE:  Another  important  suggestion  was  that  they  keep  track  of  the  costs 
involved  in  training,  participants  preparing  database  models  and  enterprise 
model,  and  JDBE  preparing  the  subject  area  of  interest  data  model,  entities 
and  data  elements  so  others  will  have  an  idea  of  cost  involved  for  future 
efforts. 

Question:  How  does  JDBE  interface  with  DIS,  or  affect  the  PDU  format 
standards?  No  answer,  but  good  question.  Iris  will  try  to  get  briefer  on  DIS, 
Protocol  Data  Units  (PDUs),  etc.  for  next  meeting  and  we  can  then  revisit 
this  question. 

Question  from  the  floor  about  the  credibility  of  this  approach:  answer  from 
the  audience  that  the  Marines  are  using  the  JDBE  approach  and  will  be 
building  a  common  database  of  standard  data  elements  thanks  to  JDBE. 
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That  one  of  the  biggest  benefits  of  this  approach  is  in  helping  people  to 
document  what  they  have  by  reverse  engineering  their  database  through 
IDEF1X  data  modeling  practices. 

JDBE  has  recently  been  coordinating  with  CIM:  with  DISA/CIM  training, 
with  Aiken  on  methodologies  for  reverse  engineering,  and  differences  in  M&S 
community  and  CIM  with  respect  to  needs  and  uses. 

Question:  Is  there  a  need  for  JDBE  to  interface  with  CALS  in  the  future? 
Answer,  doesn’t  seem  to  be  a  need  at  this  time. 

Question  from  SDIO  project:  how  do  the  users  take  the  SAI  models,  use  them 
and  maintain  and  update  them?  Answer  someone/organization  has  to  take 
responsibility  for  maintaining  the  data  models  and  entities  and  attributes 
and  recalling  the  SAI  group  when  appropriate  due  to  changes.  It  is  currently 
unclear  who  should  have  responsibility  for  this. 

JDBE  today:  changed  from  developing  military  standard  to  developing 
military  handbook;  distributed  the  third  version  of  the  JDBE  methodology 
paper;  have  conducted  two  training  classes;  are  evaluating  DISA  training  for 
further  use;  have  completed  two  project  models;  schemas  for  the  repository, 
dictionary,  and  directory  are  in  draft  form,  and  they  have  initiated 
interactions  with  CIM  groups. 

(12)  Lessons  learned  from  JDBE  IDEF1X  classes:  led  by  John 
McDonnell  (because  the  previous  brief  generated  so  much 
discussion,  there  was  only  about  10  minutes  left  for  this) 

Performance  of  students:  quick  in  picking  up  IDEF1X,  but  those  without 
experience  with  PC  windows  have  problems  in  using  the  Erwin  tool  within 
the  windows  environment.  Lesson  learned  is  to  be  sure  a  student  without  PC 
windows  experience  is  paired  with  one  that  knows  PC  windows.  They  went 
over  the  organization  representation  of  students  in  the  class  and  they  seemed 
to  come  from  a  wide  variety  of  organizations.  The  student’  class  evaluations 
were  quite  positive. 

(13)  Brief  and  demo  of  Army  M&S  Catalog:  Darlene  Pittenger  and 
Wanda  Wharton 

Wanda  Wharton  is  the  system  administrator  of  the  Army  M&S  Catalog.  The 
Catalog  resides  on  a  PC  running  MS/DOS.  It  has  been  designed  and 
implemented  as  an  Infobase/Folio  Views  application  and  its  services  are:  to 
maintain  catalog  and  service  updates,  provide  search  and  retrieval  to  remote 
users,  distribute  extracts  to  other  catalogs,  and  to  communicate  with  the 
M&S  community.  The  value  of  the  Catalog  is  very  dependent  on  the 
information  the  Army  proponents  supply  and  its  current  entries  were  taken 
from  the  J-8  Catalog.  The  Catalog  is  currently  undergoing  beta  testing  by  3 
sites  (very  successfully)  and  will  be  available  for  general  use  after  May  31st. 
Each  entry  is  a  folio,  and  groups  are  collections  of  folios. 
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The  demonstration  was  very  impressive.  There  is  no  user  manual,  self-help 
is  built  into  the  system.  Remote  users  need  to  use  VT100  keyboard  emulation 
mode  and  there  was  some  discussion  about  support  for  other  terminal  types. 

It  is  designed  so  that  the  first  browsing  screen  of  a  M/S  shows  the  most 
critical  data.  There  is  excellent  support  for  exact  queries,  and  sophisticated 
text-based  searches  (but  not  for  soundex  searches).  Catalog  data  will  be 
validated  before  it  is  entered  (proponents  do  not  enter  it  directly)  and  for  each 
M/S  V&V  information  is  supplied  by  the  proponent  and  accreditation 
information  by  the  accrediting  authority.  They  estimate  that  400  M/S  will 
take  up  about  1  megabyte  of  storage.  The  Army  has  agreement  to  be  able  to 
distribute  a  runtime  version  of  Folio  with  the  Catalog  for  individual  use. 
Currently,  downloading  this  takes  about  25  minutes  at  2400  Baud.  Lana 
McGlynn  said  the  Army  is  glad  to  make  the  software  available  to  other 
services  and  that  the  contract  vehicle  is  in  place  and  would  allow 
customization  of  software. 

(14)  Report  on  TRAC  Automated  Data  System  (TADS)  data  activities: 
Howard  Haeker 

TADS  is  a  method  to  electronically  request,  receive,  authenticate,  graphically 
display,  mathematically  transform,  and  reformat  data  from  data  providers 
into  TRADOC’s  combat  development  models.  It  supplies  data  to  12  active 
models  and  more. 

They  have  recently  completed  developing  categories  for  TADS  technical  data. 
There  are  11  identified  categories:  equipment  performance,  equipment 
characteristics,  unit  performance,  scenario,  environment,  force  description, 
tactics/doctrine/operational,  test,  human  factors,  geopolitical,  and  logistics. 

Howard  went  through  the  Army’s  M&S  data  element  submission  life  cycle: 
proposed,  candidate,  approved,  installed,  archived.  Data  elements  are 
proposed  by  their  originator  when  they  are  under  development  and  the 
originator  wants  the  Army  subject  area  experts  to  start  evaluating  the  data 
element  informally  as  a  standard.  It  moves  to  the  candidate  stage  when  it  is 
completely  developed  where  it  undergoes  more  stringent  expert  evaluation. 

It  then  moves  into  the  approval  phase  where  the  ICP  (Information  Class 
Proponent)  must  formerly  approve  it  and  it  is  then  installed  in  the  Army 
Data  Dictionary.  Lana  McGlynn,  as  the  ICP  for  M&S,  wants  most  of  the 
review  to  take  place  in  the  proposed  and  candidate  phases  so  that  actual 
approval  can  be  done  quickly.  One  assumes  that  once  it  gets  into  the  Army 
Data  Dictionary,  it  will  go  through  some  process  to  be  nominated  to  the  DoD 
CIM  level.  (I  see  a  need  to  make  repositories  for  proposed,  candidate,  and 
service  approved  DEs  available  through  searches  to  everyone  across  DoD  so 
we  don’t  get  duplication  of  effort  in  developing  DEs  in  different  organizations 
at  the  same  time.) 

Howard  addressed  several  problems.  The  top  of  the  list  is  complex  data  and 
data  dictionary  limitations  in  describing  complex  data.  Another  problem  he 
identified  (which  will  probably  become  worse  in  the  future  when  more  and 
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more  people  are  involved  in  data  standardization)  is  the  overload  on  the 
network  when  he  tried  to  read  the  Army  DISC4  dictionary.  Since  the  Army 
data  administration  group  has  moved  into  CIM,  the  ADD  will,  probably  in  the 
future,  be  a  partition  in  the  DDRS.  However,  there  will  be  DoD-wide 
contention  for  use  of  the  DDRS  so  it  is  hard  to  see  how  this  problem  will 
lessen  unless  the  partitions  are  maintained  on  different  processors  and  there 
is  good  network  management  to  sense  and  prevent  congestion. 

(15)  Report  on  Army  Modeling  and  Simulation  Executive  Council 
(AMSEC)  Subcommittee  on  Data:  Erwin  Atzinger 

The  Army  Modeling  and  Simulation  Management  Office  (AMSMO)  is  the 
DMSO  of  the  Army.  The  Army  Modeling  and  Simulation  Executive  Council 
(AMSEC)  is  the  AMSMO  advisory  body  and  is  headed  by  Walt  Hollis.  The 
AMSEC  Data  Subcommittee  is  the  focal  point  for  the  Army  AMSEC  on 
matters  related  to  data  development  (management).  The  AMSEC  Data 
Subcommittee  provides  guidance  to  ICP  (Lana  McGlynn)  for  Army  data 
modeling  of  the  M&S  process,  is  the  interface  to  the  DMSO  Task  Group, 
advises  AMSEC  on  AMIP/SEMTECH  program,  provides  fora  for  Army  data 
development  and  management  issues  relevant  to  M&S  and  recommends 
policy  and  procedural  guidance  (re  data  standardization  and 
interoperability).  A  current  AMSEC  initiative  was  sponsoring  the  Orlando 
TADS  and  AMSMO  meeting  to  develop  data  categories.  This  will  be  followed 
up  by  further  decomposing  these  11  categories,  and  the  agenda  also  includes 
getting  courses  in  IDEFlX  going,  etc.  Jim  Shiflett,  who  is  PMO  for  CCTT,  is 
very  anxious  to  address  complex  data  and  in  getting  the  data  community 
involved  in  the  DIS  PDUs. 

(16)  Report  on  data  standards  activities:  Iris  Kameny 

Iris  Kameny  presented  Twyla  Courtot’s  briefing  because  Twyla  was  unable  to 
make  the  meeting.  The  briefing  covered  the  different  standard  committees  of 
interest.  Twyla’s  updates  on  IRDS,  SQL,  and  object  management  repeated 
some  of  the  information  Bruce  Rosen  had  presented  to  us  earlier. 

Twyla  also  discussed  the  IRDS  “content  module”  concept.  She  said  X3H4  are 
working  to  define  the  term  “content  module”  so  other  standards  groups  can 
create  them  for  inclusion  in  a  new  IRDS  standard.  The  new  standard  is 
expected  to  be  a  compilation  of  these  modules.  There  would,  for  example,  be 
a  content  module  for  security,  one  for  object  management,  etc.  The  IRDS 
would  knit  these  content  modules  together  into  a  functional  repository. 

Efforts  are  being  concentrated  in  defining  a  schema  by  which  the  IRDS  itself 
can  be  described.  Conceptual  graphs  are  being  investigated,  and  a  proposal 
for  a  Normative  Schema  standard  has  been  put  forward. 

The  report  on  X3L8,  the  committee  on  data  representation  standards,  covered 
interesting  efforts  on  a  framework  for  generation  and  standardization  of  data 
elements,  classification  of  concepts  for  identification  of  domains,  basic 
attributes  of  data  elements,  and  registration  and  naming  principles  for  data 
elements.  The  registration  effort  is  focusing  on  using  a  classification  scheme 
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for  unique  identity  of  elements  rather  than  relying  on  a  name.  All  these 
issues  are  very  important  to  our  effort  and  perhaps  Twyla  can  give  us  a  more 
comprehensive  briefing  at  the  next  meeting. 

(17)  Report  on  new  DARPA  BAAs  in  the  Data  Area:  Gio  Wiederhold 

Gio  gave  us  an  overview  of  the  technology  organization  in  DARPA/SISTO. 
SISTO  has  three  strategic  plans:  (1)  intelligent  systems  covers  autonomous 
systems,  interactive  problem  solving,  and  intelligent  integration  of 
information;  (2)  software  engineering  covers  SEI,  STARS,  evolutionary 
software  development,  and  software  engineering  foundations,  and 
information  technology  for  manufacturing  covers  manufacturing  automation 
and  design  engineering.  In  evolutionary  software  development,  there  are 
four  programs:  domain  specific  architectures,  PROTOTECH,  software 
development  environments,  and  persistent  object  base.  The  PROTOTECH 
program  includes  development  of  tools  for  rapid  prototyping  to  replace  the 
waterfall  method  (8120.1. ,.2).  In  the  Persistent  Object  Base  Program, 

DARPA  is  supporting:  the  OMG  standards  group  by  supporting  Texas 
Instruments  in  participating  and  writing  the  standards  document;  the  Object 
Request  Broker;  and  the  building  an  example  since  it  is  difficult  to  define  a 
specification  without  an  example. 

The  BAA  for  new  proposals  in  advanced  software  covered  6  areas:  component- 
based  software  (tools  and  languages  for  putting  components  developed  in 
different  languages  together),  domain-specific  architectures  (could  simulation 
be  a  domain  specific  area  (e.g.,  JMASS)?,  advanced  software  environments, 
high-assurance  software  (verification  vs  specification),  software 
understanding  and  re-engineering,  and  persistent  object  bases. 

In  the  interactive  problem  solving  area  there  are  program  areas  for  human 
language,  planning  and  decision  aids,  human  computer  interaction,  and  Joint 
Task  Force  ATD.  Human-computer  interaction  is  a  new  area  that  is  just 
starting  up. 

The  I3S  is  addressing  data  overload,  information  starvation,  system  rigidity, 
and  management  of  complexities.  Intelligent  mediation  acts  to  reduce  data  to 
information — current  federated  systems  are  similar  to  current  simulation 
model  interfaces — whereas  intelligent  mediation  is  managed  by  domain 
specific  experts.  (For  more  information,  Gio  referred  to  two  papers  he  has 
written,  “Mediation  Approach  to  Future  Architectures”  in  IEEE  Computer, 
March  1992,  and  a  paper  on  software  composition  in  ACM  Communications, 
November  1992.)  Main  activities  in  mediation  are  summarization,  fusion, 
generation,  and  use  of  histories.  He  used  a  system  security  officer  (SSO) 
mediator  as  an  example.  An  SSO  mediator  would  use  methods  to  summarize 
and  abstract  the  essence  from  the  multitude  of  small  audit  trail  events  to 
provide  a  higher  level,  more  meaningful  organization  of  events.  (The  lower 
level  audit  trail  is,  for  all  practical  purposes,  unreadable  by  humans.)  A 
research  issue  is  that  of  understanding  where  to  locate  mediator  nodes  for  the 
most  efficient  processing. 
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He  also  mentioned  KQML  (Knowledge  Query  Management  Language)  which 
is  an  interface  specification  language  that  provides  a  wrapper  standard  and 
has  been  written  up  in  a  document  by  Bob  Neches  at  ISI  (neches@isi.edu). 
This  runs  on  Unix  platforms. 

Gio  would  like  to  see  a  SIMQML  analogous  to  KQML  to  interface  to 
simulators.  (This  fits  with  the  current  interest  in  providing  some  kind  of 
wrappers  around  simulations  to  enable  them  to  be  more  easily  integrated  into 
larger  systems  that  require  the  interoperation  of  simulations.) 

(18)  Status  of  Navy  Verification,  Validation,  and  Accreditation 
(W&A)  Processes:  Simone  Youngblood 

Simone  began  by  showing  us  the  Navy  M&S  structure: 

—  RADM  Allen,  N81,  is  Director  of  the  Assessments  Division  of  OPNAV 
and  is  POC  for  DMSO  and  other  DoD  components 
—  CAPT  McClure,  N812D,  is  Head  of  M&S  Section  within  the  Net 
Assessment  and  Affordability  Branch  and  is  Executive  Agent  for  N81 
and  Executive  Secretary  for  Team  Mike 
—  Team  Mike  is  the  Naval  Warfare  Analytical/Modeling  and 

Simulation  Oversight  Council  (NMSOC)  that  is  technical  advisor  on 
analysis  and  M&S,  and  interface  to  DIS  Task  Force 
-  SPAWAR  31  Modeling  and  Simulation  Technical  Support  (MSTS) 
through  Navy  R&D  Centers  and  JHU/APL 

The  SECNAV  or  OPNAV  instruction  to  address  Navy  and  Marine  M&S 
issues  (similar  to  Army  Regulation  5-11)  is  expected  to  be  released  in  early 
April  1993  and  is  expected  to  contain  a  number  of  TABs  (e.g.,  Team  Mike 
charter,  M&S  master  plan  and  investment  plan)  including  VV&A  processes 
for  M&S  which  is  the  project  being  addressed  by  JHU/APL.  Status  of  the 
work:  it  was  distributed  to  Team  Mike  membership  on  February  10  for  review 
and  N812D  expects  comments  back  by  March  15.  Simone  gave  us  copies  of 
the  “Preliminary  Bibliography  for  Modeling  and  Simulation  (M/S) 

Verification,  Validation,  and  Accreditation  (WA)”  which  contains  about  250 
entries  and  has  been  distributed  to  Team  Mike  and  reps  from  the  Army  and 
Air  Force.  The  Navy  WA  process  is  based  on:  WA  being  an  integral  part  of 
the  M&S  development  process;  WA  being  moved  as  far  forward  in  the 
development  process  as  possible  (validate  the  concept);  automate  as  much  of 
the  process  as  possible;  and  formalize  WA  processes  for  future  endeavors. 

The  WA  paradigm  presented  shows  WA  at  six  stages  in  M&S  development 
with  documented  review  at  each  step:  (1)  conceptual  validation  of  the 
conceptual  model;  (2)  design  verification  of  the  M&S  specification,  (3)  code 
verification  of  the  development  code, (4)  results  verifies ti  nn  of  the  M&S 
implementation,  (5)  domain  accreditation  of  the  problem  domain,  and  (6) 
application-specific  accreditation  of  the  specific  application  including  the 
input  data.  This  will  require  getting  a  review  team  together  at  each  level. 


987 


Note,  that  the  process  is  consistent  with  the  steps  required  by  SEI  for  the 
software  development  process.  They  have  proposed  four  levels  of 
accreditation:  Inspection  (a  few  manweeks),  general  (less  than  6 
manmonths),  robust  (manyears),  endorsed  (cost  may  exceed  M&S 
development). 

Questions  were  asked  about:  dealing  with  stochastic  models  which  is  more 
difficult  than  dealing  with  deterministic  models;  modifications  to  models 
requiring  re-accreditation;  the  need  to  re-certify  data  that  has  been  changed 
due  to  updates  (version  changes);  and  need  to  re-verify  derived  data  even  if 
the  data  it  was  derived  from  was  certified  (really  verifying  the  derivation 
process). 

Simone  discussed  the  new  DMSO  WA  Task  Group  which  held  a  kickoff 
meeting  on  17  February  and  is  expected  to  run  for  6-8  months.  Its  objective 
is  to  produce  a  policy  statement  on  WA  for  all  services  (an  instruction, 
handbook,  and/or  a  pamphlet.  We  discussed  who  would  lead  that  activity  and 
Iris  incorrectly  thought  it  was  Paul  Davis.  At  this  time,  there  is  no 
designated  leader. 

N812D  also  formally  submitted  a  proposal  to  DMSO  for  a  WA  Institute  that 
would  be  analogous  to  the  Software  Engineering  Institute  and  the  Institute 
for  Simulation  and  Training. 

(19)  Report  on  (SDIO)  Analytic  Tool  Box  (ATB):  Anne  Marie  Gnacek 

Objectives  of  the  ATB  project  are  to  provide  SDIO  with  an  institutionalized 
collection  of  models,  simulations,  and  data  that  will  support  GPALS 
architectural  examination,  development,  test,  and  evaluation  requirements; 
provide  capability  to  match  an  analyst  to  a  model;  and  provide  a  management 
tool  for  SDIO  Deputies  and  Directors.  The  problem  is  that  SDIO  has  to 
report  to  Congress  that  SDS  will  work  but  SDIO  has  not  established  baseline 
of  accredited  M&S,  no  methodology  to  build  confidence  in  models  quickly  and 
cost  effectively,  and  some  differences  in  simulation  results  are  directly 
attributable  to  use  of  “nonstandard”  databases.  ATB  should  provide:  basis  for 
comparative  analysis  and  trade  studies;  enhanced  SDIO  ability  to  explain 
differences  in  model  results;  confidence  building;  establishment  of  learning 
curves  and  lessons  learned;  driving  toward  accreditation  (but  not  integral 
part  of  ATB);  cost  effective  in  using  M&S  to  support  acquisition  process; 
capability  to  match  analyst  to  model  (software  revise);  and  use  of  objective 
assessments/procedures  by  joint  team  of  experts.  The  ATB  approach  is 
basically  that  of  determining  customer  requirements;  aiding  in  model 
selection;  after  model  is  identified  for  use  do  confidence  assessment,  model 
enhancement,  and  configuration  management;  then  go  into  the  WA  process 
(including  flight  and  testing  program)  and  finally  do  model  maintenance. 

Models  could  be  submitted  to  the  ATB  from  Services  if  they  have  SDIO 
applicability  and  even  before  they  had  undergone  WA  by  the  Service.  For 
models  designed  for  SDIO  usage,  ATB  would  do:  configuration  management  if 
asked  to  (or  serve  on  Configuration  Management  boards).  Confidence 


988 


assessment  for  SDIO  developed  models  consists  of  four  steps:  verify  the 
intended  use  of  a  baseline  model;  do  continued  review  of  the  model;  V&V  of 
selected  portions  of  models  independent  of  developers  but  based  on  what  the 
SDIO  sponsor  wants  them  to  do  and  continued  V&V  of  model  sections.  They 
showed  5  levels  of  M&S  support  using  ATB  and  other  procedures: 
architectural  analysis,  low  confidence  models,  medium  confidence  models, 
high  confidence  models,  and  W&A  models.  However,  they  seemed  to  be 
saying  that  given  the  perspective  of  the  JHU/APL  W&A  study  for  the  Navy, 
they  are  not  doing  accreditation.  I  believe  they  said  they  will  do  W&A  and 
CM  for  the  tools/software  that  are  a  part  of  the  operation  of  the  testbed  and 
optionally  offer  this  service  to  developers  who  will  be  submitting  tools  to  the 
testbed  or  to  tools  that  SDIO  wants  them  to  do  V&V  on.  (It  would  be 
interesting  to  go  through  the  JHU/APL  six  steps  and  see  at  which  of  these 
steps  the  ATB  project  would  offer  independent  V&V  to  developers.) 

The  ATB  was  developed  on  a  PC  and  is  currently  running,  on  a  classified 
network,  on  a  Sun  using  the  Oracle  DBMS  and  contains  6  models  (out  of 
approximately  500  SDIO  models).  In  the  future  they  expect  to  also  run  an 
unclassified  version.  In  summary  it  provides:  a  collection  of  accessible  and 
verified  and  validated  M/S  and  data;  configuration  management  of  those 
resources  consistent  with  SDIO  policy;  and  establishing  methodologies  to 
support  confidence  assessments,  appraisals,  and  W  leading  to  accreditation. 

(20)  Department  of  Defense  Strategic  Planning  for  Intelligence  Data 
Administration:  Linda  Calvert 

Linda  went  over  some  background  including  the  DoD  Data  Administration 
Strategic  Plan(s)  (DASP)  planning  cycle  which  requires  that  all  DoD  FDAds 
and  CDAds  submit  their  DASPs  to  the  DoD  DA  by  30  December.  The 
Intelligence  DASP  includes  NSA,  DIA,  and  CIO  plans.  The  DoD  DASP  vision 
of  the  future  includes  operational  central  repository;  standard  data 
(architecture,  models,  entities,  data  elements);  use  of  common  procedures  and 
tools;  quality  data;  education,  training,  and  consultation  services;  effective 
infrastructure;  and  (not  on  list)  data  security  policy  and  procedures.  She 
gave  us  an  excellent  diagram  of  the  DASP  DoD  DAd  framework  and 
identified  POCs  within  DISA/CIM,  (Tom  Weber,  talk  to  him  about  the 
taxonomy  for  accessing  products  in  the  repository),  and  for  intelligence 
(Charles  Hawkins  and  James  Davidson).  The  intelligence  DAd  framework 
shows  7  functional  activity  managers  with  CIO  responsible  for  IMINT,  NSA 
for  SIGINT,  and  DIA  for  GMI,  S&T,  CM,  MASINT  and  HUMINT. 

Intelligence  data  issues  include:  need  for  secure,  compartmentalized  data 
elements  and  databases  and  merging  of  secure  with  open  source  data;  users 
of  data  are  needed  to  do  analysis;  complex  data  types;  overlapping 
international,  national  and  intelligence  organizational  procedures, 
definitions,  and  standards;  and  legacy  and  evolving  M&S  systems.  There  is  a 
combined  intelligence  working  group  being  formed  to  deal  with  these  issues 
(we  should  coordinate  with  them)  and  DISA/CIM  action  plans  include  dealing 
with  security  requirements.  Security  is  a  big  issue.  For  example,  the 
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intelligence  community  has  to  address  the  security  level  of  meetings  in  order 
to  meet.  An  example  of  changes  is  that  during  a  Copernicus  exercise 
classified  data  was  downgraded  to  be  used  in  the  exercise. 

There  is  a  formal  intelligence  M&S  group  that  maintains  a  catalog  of  M&S 
models  in  the  intelligence  community,  the  majority  of  which  are  unclassified. 
For  general  information,  Linda  noted  that  it  is  taking  1.5  times  as  long  to  re¬ 
engineer  data  in  legacy  systems  as  to  build  a  new  data  model. 

View  of  new  post  cold  war  era  for  M&S:  models  must  be  flexible  to  accept 
complex  data  from  new  sources  quickly;  M&S  must  expand  to  include  new 
areas  such  as  economic,  agricultural,  social;  security  classifications  and 
compartmentalizations  must  be  re-examined  for  inclusion  rather  than 
exclusion;  and  intelligence  information  must  be  shared  more  widely  for 
peaceful  purposes. 

(21)  TECNET  Brief:  George  Hurlburt 

TECNET  is  a  user  controlled  network  governed  by  a  Joint  Service  Steering 
Committee,  service  funded,  designed  for  all  DoD  Test  and  Evaluation 
Communities  (developmental,  operational,  all  services)  to  promote  efficiency 
of  T&E  within  DoD,  provide  forum  for  T&E  players,  relieve  communications 
bottlenecks  and  problems,  increase  awareness  through  sharing.  Services 
include:  e-mail,  bulletin  board  facilities,  binary  file  repository  system, 
database  support  (directories  and  private  databases),  specialized  user 
services  (DoD  News,  Electronix  Early  Bird”,  Aerospace  Daily,  CBDs,  etc.), 
integrated  fax,  and  extensive  help.  Its  available  all  the  time  and  can  be 
accessed  through  DDN  and  Federal  telephone  system.  TECNET  is  on  a 
DSNET  machine  and  is  C2  accredited  to  run  system  high  at  the  secret 
classification  level  at  Aberdeen.  All  services  are  available  at  system  high 
except  for  downloading  and  faxing  but  do  have  file  transfer  available.  It  has 
over  3,000  registered  users,  148  active  bulletin  boards,  supports  a  number  of 
databases,  has  liaison  with  many  organizations,  and  protocols  support  kermit 
transfer,  simple  mail,  telnet  access  and  FTP. 

The  future  vision  is  to  systematically  migrate  existing  TECNET  resources  to 
create  a  standards  compliant,  multi-level  secure  communications  and 
processing  capability  that  links  DoD  T&E  entities  to  a  shared  but  controlled 
user  community  information  resource.  Plan  to  move  from  present 
configuration  OSI  (TCP/IP,  X.25),  Unix,  C-2  trust,  1200-9600  Baud,  DBASE, 
system  high,  RISC,  MILSPEC,  C,  DDN  host)  to  future  (  GOSIP,  POSIX,  B-2 
trust,  T-l,  MLS  RDBMS,  MLS,  Multi-RISC,  CALS,  Ada,  Internet).  Research 
initiatives  are  for  state-of-the-art  internet  GUI,  file  and  fax  manipulation, 
distributed  data  (common  data  dictionary,  heterogeneous  database 
exchange),  multi-level  secure.  They  plan  to  use  JDBE  methodology  to  model 
their  T&E  data  dictionary.  MLS  has  to  address  the  data  aggregation  problem 
(aggregated  data  should  be  at  a  higher  classification  level  than  the  data  it 
was  aggregated  from).  TECNET  will  be  publishing  the  results  of  their 
security  experiment  by  September  1993  and  DMSO  will  receive  a  copy.  When 
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DMSO  clients  apply  for  TECNET  use,  you  need  to  let  them  know  on  the  form 
that  you  are  a  DMSO  user. 

They  have  a  real  heterogeneous  database  problem  to  access  range  data  for 
different  databases.  Problems  include  outdated  documents,  unavailable  data, 
no  standard  terminology,  misconception  of  need,  and  ranges  are  not  able  to 
present  their  capabilities  effectively.  At  present  they  have  used  the  TRW 
TDIE  tool  to  service  canned  queries  by  mapping  the  query  and  the  database 
schema  to  the  range  data  but  this  will  not  work  for  ad  hoc  queries.  Also  this 
may  be  difficult  to  maintain,  i.e.,  when  a  data  schema  changes,  one  would 
need  to  update  all  the  mappings  affected  by  the  change. 

TECNET  development  started  at  the  same  time  as  the  DMSO  Information 
System  development,  but  appears  to  be  ahead  of  the  DMSO  IS.  Perhaps  we 
should  look  into  possibility  of  acquiring  some  of  their  software?  Their 
contract  development  agencies  were  Clemson  U,  TRW,  MITRE,  AT&T  and 
Sun. 

8.  BRIEFS  AND  DISCUSSION  OF  GEO-SPATIAL  DATA 

(22)  DMA  brief  on  Geo-Spatial  Information  to  include  new  available 
products  and  prototypes  (e.g.,  Digital  Chart  of  the  World),  terrain 
data  models,  DMSO  Project  205A,  and  products  of  the  future,  and 
JCS  MOP  Dave  Danko  and  Bob  Jacober 

Digital  Chart  of  the  World  (DCW)  goals:  to  establish  a  suite  of  standards  for 
vector  digital  MC&G  products  to  support  direct  user  interaction,  compatible 
with  the  DMA  Digital  Production  System  (DPS),  meet  product  requirements 
at  many  scales,  designed  for  use  in  wide  range  of  computer  environments, 
and  to  develop  a  product  specification  using  the  new  standards  to  support 
robust  GIS  analysis  and  to  support  graphics  display.  Thus  goals  are  to 
develop  standard  and  product  (includes  wealth  of  data)  which  includes 
application  software  for  accessing  standard  data  sets,  global  and  theater 
planning  and  assessment  capability,  and  briefing  and  decision  graphics. 
(ARCINFO  will  support  the  DCW  standards  within  the  next  few  months.)  Co¬ 
developers  of  DCW  are  Australia,  Canada,  and  UK  (through  use  of  Nunn 
amendment)  and  US  contractors  include  ESRI,  Loral,  GEOVISION,  and 
SAIC.  A  prototyping  approach  was  taken  to  incrementally  develop  the 
standards.  Developed  4  prototypes:  (1)  small  dataset  with  contractor 
proprietary  code;  (2)  new  non-proprietary  code,  more  data,  expanded 
bandwidth;  (3)  refined  structure  and  format  to  include  wider  variety  of  maps 
and  charts,  more  data,  wider  bandwidth;  and  (4)  final  structure  and  initial 
production  products. 

The  vector  product  format  (VPF)  (MIL-STD  600006)  describes  conceptual 
model  (DIGEST  based),  physical  model  (relational),  supports  various  levels  of 
topology  and  integration,  inter-tile  topology,  and  spatial  and  thematic 
indexing.  It  is  a  self-describing  format  (using  headers),  has  on-line  dictionary 
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to  fully  describe  feature  codes,  and  product  has  quality  data  (i.e.,  polygons, 
attributes,  etc.  checked  back  to  original  source).  Product  consists  of  five 
libraries  (browse,  North  America,  Europe  and  Northern  Asia,  South 
American  and  Africa,  and  Southern  Asia  and  Australia)  on  4  CD-ROMs  (each 
with  own  browse  library),  a  total  of  1700  MB  of  information,  and  some 
products  are  available  through  DMACSC  and  USGS.  DCW  is  not  GIS,  it  can 
retrieve  information  through  query  by  attributes  but  does  not  do  spatial 
analyses.  DMA  vector  products  include:  World  Vector  Shoreline,  Digital 
Nautical  Chart,  Vector  Smart  Map  (1:250,000  and  1:50,000),  and  Urban 
Vector  Map.  Coverages  include  boundaries,  elevations,  hydrology,  individual 
objects  (processing  plant,  storage  depot,  etc.),  physiography,  population, 
transportation,  utility,  vegetation.  DCW  has  17  layers  and  features  are 
supported  as  lines,  points  and  vectors.  They  have  digitized  the  cartographic 
to  look  like  geographic  in  that  compiled  roads  can  be  supported  going  through 
built-up  area  though  there  is  no  room  on  paper  map  to  show  these.  Also  need 
to  be  sure  that  polygons  are  closed  in  order  to  compute  areas,  also  if  paper 
map  showed  stream,  road,  railroad  in  canyon,  it  probably  separated  them  and 
these  can  be  put  together  in  proper  place  for  geographic  presentation.  Noted 
that  1:250,000  vector  maps  for  within  US  and  nautical  maps  are  releasable  as 
products  to  public  but  rest  are  not  releasable  to  public. 

DMA  strategic  plan  2000:  expand  DPS  to  support  crisis  response  to  hot  spots 
to  provide  the  user  the  most  current  information,  the  right  information  at  the 
right  time  (will  be  large  customer  accessible  database).  Global  Geospatial 
Information  (G2I):  define  “geospatial  information;  articulate  transition  to 
geospatial  information  vs  products;  create  “gateway”  project  of  the  customer 
accessible/exportable  “geospatial  information”  database;  and  change 
collection  strategy  to  provide  global  coverage  (land,  ocean,  aeronautical, 
geophysical).  In  future  will  have  electronic  online  catalog  and  will  be  able  to 
transmit  or  distribute  standard  products  or  tailored  database  on  standard 
media. 

CJCS  MOP  31:  DoD  components  and  Federal  agencies  submit  MC&G 
support  requirements  and  justifications  in  accord  with  appropriate  DMA 
instructions.  Director  DMA,  etc.  in  accord  with  DoDD  5105.4  reviews  and 
validates  submitted  requirements  and  priorities  to  ensure  compliance  with 
MOP.  DMA  produces,  maintains,  and  distributes  MC&G  products  over 
specific  geographic  areas  based  on  the  prioritized  MC&G  support 
requirements.  The  revised  MOP  31  includes  a  new  priority  system, 
emphasizes  country  precedence  list,  includes  level  of  risk  as  consideration, 
submission  is  ongoing  process,  and  DMA  submits  to  CJCS  and  ASD(C3I). 
DMA  organizational  objectives  are  to:  determine  and  satisfy  area 
requirements;  give  crisis  support;  improve  contingency  support  posture;  meet 
future  demands;  and  support  standards  and  interoperability. 

DMSO  Terrain  Requirements  and  Standards  Project  objectives:  to  survey 
community  to  determine  content,  accuracy  and  location  requirements  for 
digital  geographic  data  to  support  M&S,  survey  community  to  determine 


992 


spatially  related  value-added  data  requirements  to  support  M&S;  prototype 
digital  geographic  datasets  to  support  M&S  applications;  assess  commercial 
equipments  and  methods  for  production  of  digital  geographic  data;  and  begin 
production  of  digital  geographic  data  to  support  M&S. 

To  date:  survey  methodology  was  completed  in  September  92,  will  complete 
all  surveys  by  28  February  and  report  to  DMSO  by  15  May  1993.  Made 
approximately  125  on-site  visits  (will  go  to  250  before  complete)  with  sites 
determined  by  service/agency.  SAIC  is  under  contract  for  aggregation, 
consolidation,  and  in-depth  quantitative  analysis  of  completed  sample. 
Preliminary  findings:  all  users  predict  increasing  use  of  M&S,  boundaries 
defining  traditional  application  areas  are  blurring,  and  there  is  an  increasing 
requirement  for  MC&G  data  to  support  analytical,  non-visual  applications. 
The  draft  product  specification  should  be  available  by  15  June  1993,  first 
prototype  by  15  July  and  second  prototype  by  December  31,  1993. 

(23)  Discussion  of  Geo-Spatial  Information  Needs,  Standards,  etc.  led 
by  Paul  Birkel 

Question:  Commonality  of  this  project  with  project  2851:  DMA’s  past  efforts 
didn’t  address  project  2851,  a  tri-service  initiative.  Project  2851  has 
concurred  on  a  standard  interface  format  for  simulators  and  they  can  take 
DMA  data  in  standard  DMA  format  and  translate  it  into  project  2851 
standard  format.  Originally  Project  2851  standards  were  developed  by 
Service  group  with  Service  funding,  DMA  is  now  beginning  to  work  with 
them. 

Question:  how  does  USGS  new  object  model  standard  relate  to  DMA  DCW 
relational  model  standard?  Answer:  need  to  get  USGS  to  come  and  present 
with  DMA  next  time  and  discuss  how  these  two  standards  relate. 
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Appendix 

E.  NOTES  FROM  THE  6TH I/DB  WORKSHOP  HELD  JULY  28-29, 

1993  AT  EDA. 
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1.  AGENDA 

MEETING  OF  DMSO  I/DB  TASK  GROUP 
WEDNESDAY,  JULY  28, 1993 

UPDATE  ON  DMSO  HAPPENINGS 

8:00 — 8:20  Welcome  and  DMSO  update:  CDR  Mike  Lilienthal 

(DMSO) 

8:20 — 8:35  Introduction  to  Dr.  Chien  Huo  who  will  be  supporting 

DMSO,  and  an  overview  of  the  JIEO  M&S  support 
activities:  Ms.  Iris  Kameny/Dr.  Chien  Huo  (JIEO) 

8:35 — 8:50  Update  on  DMSO  Information  System:  Mr.  Ken  Wimmer 

(SAIC)  and  I/DB  Partition:  Ms.  Iris  Kameny  (RAND) 

8:50 — 9:00  M&S  Information  Analysis  Center:  Mr.  Ernest  Smart  (U 

of  Central  Florida/Institute  for  Sim  and  Training) 

REPORTS  FROM  NEW  M&S  ORGANIZATIONS 

9:00 —  9:20  New  Air  Force  M&S  organization:  Dr.  James  Vernon 

(AF/XOMT) 

9:20 —  9:40  *New  Marine  M&S  organization:  Mr.  Frank  Hoffman 

(USMC) 

9:40 — 10:00  Intelligence  Community  M&S  Coordinating  Group  and 

intelligence  models:  Dr.  Sid  Kissin  (NSA) 

10:00—10:20  Break 

DATA  SECURITY 

10:20 — 10:40  Security  CONOPS  for  Intelligence  Community  Catalog  of 

M&S:  Mr.  John  Griffiths  (IC  M&S  Coordination  Group) 

10:40 — 11:00  Defense  Information  System  Security  Program 

(DISSP):Mr.  Hart  DeGraffi 

DATA  ADMINISTRATION,  STANDARDIZATION  AND  MODELING  ACTIVITIES 

11:00 — 12:00  DoD  Enterprise  Model:  Mrs.  Bunnie  Smith  (ODASDdS)) 

12:00 — 1:00  Lunch 

1:00 —  1:30  Update  on  DoD  Data  Administration  Program  (including 

reverse  engineering,  repository,  etc.):  Ms.  Becky  Harris, 

Ms.  Lynn  Henderson  (DAPMO) 

1:30 —  2:00  Report  on  IDEF  Users’  Group  meetings  and  issues:  Mr. 

John  Tieso  (ODASD(IS)) 

2:00 —  2:30  Air  Mobility  Command  Information  Resources  Repository 

System:  Major  Doug  Hurd  (AF/HQ/AMC/SCTI) 

ATCCIS  Battlefield  Generic  Hub  Data  Model:  Iris 
Kameny  for  Major  Matt  O’Hanlon  (NATO/ATCCIS) 


2:30—  3:00 
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3:00 —  3:30  Break 

3:30 —  4:00  Update  on  C2  data  modeling  activities  at  JIEO:  LTC  Mike 

Robinson  (JIEO/CFS) 

4:00 —  4:30  MORS  Mini-Symposium  on  M&S  Data  Issues  (Nov.  16- 

18):  Mr.  Howard  Haeker  (Army/TRAC) 

4:30 —  5:00  Update  on  complex  data  issues:  Ms.  Iris  Kameny  (RAND) 

THURSDAY,  JULY  29, 1993 

ENVIRONMENTAL  DATA  MANAGEMENT  AND  DATA  STANDARDS 

8:00-  8:30  Navy  Oceanographic  and  Atmospheric  Master  Library 

and  data  standards:  Mr.  Alan  Chappel  (Navy) 

8:30 —  9:00  EOSDIS  overview:  Ms.  Debbie  Blake  (NASA) 

9:00 —  9:45  Developments  in  spatial  data  standards:  Mr.  Dave  Danko 

(DMA)  Joint  MC&G  Interoperability:  Col  Rich  Johnson 
(DMA) 

9:45 — 10:15  Project  2851  standards;  Major  Kent  Johnson  (Aeronautics 

System  Command/YTMS) 

10:15—10:35  Break 

10:35 — 11:00  *Army  environmental  data  transformation  standards:  Mr. 

Robert  Atkins  (Army  TEC) 

11:00 — 11:25  Dynamic  Environment  and  Terrain  Modeling  in  DIS:  Mr. 

Jeff  Turner  (Army  TEC) 

11:25 — 11:55  STRICOM  DIS  standards  initiatives:  Mr.  Gene  Wiehagen 

(STRICOM) 

11:55 — 12:20  Distributed  Interactive  Simulation  standards  process:  Dr. 

Chien  Huo  (JIEO/CFS) 

12:20 — 1:10  Lunch 

DATA  STANDARDS  ACTIVITIES  IN  M&S  PROJECTS/PROGRAMS 

1:10 —  1:30  Standardization  of  moving  models  in  virtual  simulation: 

Mr.  Farid  Mamaghani  (consultant  to  IDA  and  PM-CATT) 
1:30 —  2:00  Close  Combat  Tactical  Trainer  (CCTT)  update  and  data 

standards:  Mr.  Rob  Wright  (CCTT/RCI) 

2:00 —  2:30  Universal  Threat  System  for  Simulation  (UTSS):  Clay 

Putman  (GPS  Tech  supporting  Navy/UTSS) 

2:30 —  3:00  Data  Base  System  Upgrade  Project:  LTC  Rayford 

Eubanks  (JS) 

3:00 —  3:30  Break 

3:30 —  4:00  Operations  Analysis  and  Simulation  Interface  System 

(OASIS):  LTC  Dan  Hogg  (JS/J8) 

4:00 —  4:30  Joint  Data  Base  Elements  (JDBE)  experience  with 

developing  subject  area  information  models:  Mr.  Steve 
Matsuura  (Army/EPG) 

4:30 —  5:00  Summary  and  Wrapup:  led  by  Dr.  Chien  Huo 

*  These  briefings  were  not  given 
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Name/Affiliation  Phone  Fax  Email 

Tom  Adrian,  CACI  (703)  875-2911  (703)  875-2904 

Cy  Ardoin,  IDA  (703)845-6647  (703)845-6848  ardoin@ida.org 

James  Augins,  Navy  (619)  553-6085  augins@nosc.mil 

Robyn  Benensohn,SAIC  (619)  546-623  (619)  546-6709  robyn@jupiter. 

saic.com 

Paul  Birkel,  MITRE  (703)  883-6399  pbirkel@mitre.org 

Bob  Bishop, DTIC-AP  (703)  274-7662  (703)  617-7087  rbishop@dgis. 

dtic.dla.mil 

Don  Blanton,  AMSAA  (410)  278-3368  (410)  278-6242  blanton@brl.mil 

Larry  Buchsbaum,  NAWC  (215)  441-1534  buksbaum@nadc.navy.mil 

William  Burch,  Navy  (703)  578-2587  (703)  379-8077  or  578-2568 
Chuck  Burdick  (703)  759-1407  (703)  759-1450 

Linda  Calvert, MITRE  (703)  883-6326  lcalvert@mitre.org 

Gary  Carlson,  (619)  553-3017  (619)  553-5933-fax 

Virginia  Castor, ODDRE  (703)  614-0212  castor@ajpo.sei.cmu.edu 

Herman  Cisneros,SSDC  (205)  955-4527  (REPLACES  GARY  MAYS) 

Jacquelyne  Neville  (703)  683-7287  (703)  418-0775 

Twyla  Courtot, MITRE  (703)  883-7343  (703)  883-6991  courtot@mitre.org 

David  Danko,  DMA  (703)  285-9238  (703)  285-9383 

Tina  De  Angelis,  AF  (310)  363-3253  (310)  363-1753  deangelitm@cn. 

laaib.af.mil.ucsd.edu 

Tim  Doane,  GPSC  (703)  271-7700  (703)  271-8566 

Christine  Donohue,USN  (703)  693-5928  (703)  693-7329  donohuec@cc. 

ims.disa.mil 

John  Eisenhardt,  (313)  761-5836  (313)  761-5368  FAAC,Inc.76104. 

607@compuserve.com 

Peggy  Gordon,  AF  (703)  693-5745  (SEE  MAJ  JACK  JORDAN) 

LTC  Chris  Grates, USN  (904)  884-6926  gratesc@vaxl.jwc.af.mil 

Peggy  Gravitz,Colsa  (205)  922-1512  (205)  971-0002  x2170 
John  Griffiths, Intel.  (703)  820-2841  Same  as  phone  # 

CDR  Charlotte  Gross  (703)  746-7939  (703)  746-9396  cgross@ddi.c3i. 

osd.mil 

Lupy  Haddad,  RCI  (407)  282-1451  (407)  658-9541 

Howard  Haeker, USA/TRAC  (913)  684-3030  (913)  684-3866  haekerh 

©tracer.army.mil 

Lynn  Henderson  (DAPMOX703)  285-5377  (703)285-5403 
Scott  Herman,  DBMd  (202)  863-9960  (202)  863-8407 

Dan  Hogg,  JCS/J8  (703)697-8899(703)693-4601  dhogg@mhljs.mil 

Chien  Huo,  JIEO  (703)  487-8036  (703)  487-8038  huoc@cc.ims.disa.mil 

Major  Doug  Hurd,HQAMC  (618)  256-5663  (618)  256-5673  mscti7@mhs.8aib.af.mil 
George  Hurlburt,  Navy  (301)  826-3625  (301)  826-3134  hurlburt@ 

technetl.JCTE.JCS.mil 

Mike  Hopkins,  (813)  830-6210  (813)  830-4919 

CSC  for  CENTCOM  Phil  Hwang  (703)  285-9286  (703)  285-9396 
Mcjor  Bill  Johnson,  USA  (407)  380-4328  (407)  380-4201 

Major  Jack  Jordon,  (703)  693-5745  jajordan@sysp3.hq.af.mil 
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Iris  Kameny,  RAND  (310)  393-0411  (310)  393-4818  kameny@rand.org 
Martin  Katz  katz@cseic.saic.com 

Kenneth  Kaufmann,NCCOSC  (619)  553-6098  (619)  553-6083  kaufmann@nosc.mil 
Edward  Khedouri  (601)  688-4556  (601)  688-5759  N22%N2%CNOC@ 

comis.conoc.navy.mil 

Bob  Kero, Argo nne  Lab  (708)  252-3752  bkero@eid.anl.gov 

Sid  Kissin,  NS  A  (301)  688-0562 

K.  Konwin,  AFSAA  (703)  697-5616  (703)  697-3441 

Richard  Kruger  (703)525-0081  (703)  524-1643  kruger@cpms.saic.com 

Chris  Landauer,  Aerospace  (703)  318-5403  psc@aero.org 

Steve  Lawyer,  IDA  (703)  845-6696  lawyer@ida.org 

Dan  Lewis,  DISA/CIM  (703)  536-6900  (703)  536-7480 

Mike  Lightner  JMASS  (513)  476-4464  (513)  476  4746 

Mike  Lilienthal,DMSO  (703)  998-0660  (703)  998-0667  mlilient@dgis.dtic.dla.mil 
Ernie  Lucier,NASA/SED  (202)  358-0772  lucier@nhqvax.hq. 

D.  Lunceford,CCTT  (407)  380-8193  luncford@chann.isi.edu.nasa.gov 

Bill  Macon,  (703)  325-0918  (703)  325-2964 

Major  Doug  Martin  (703)  998-0660  (703)  998-0667 

Janet  McDonald,  USA  (602)  538-4958  (602)  538-4973  mcdonald@hua 

chuca-emh7  .army  .mil 

Rich  Moore  (407)  282-4583  moore@orlando.loral.com 

Tom  Nabors  (601)  688-5248 

Jack  Nicklas,  RCI  (703)  893-6120  (703)  893-0917 

Chris  Olson  (703)  683-7287 

Bob  Overholt  (215)  897-5546  (215)  897-6707 

LTC  Ron  Parker,  AF  (703)  693-5745  (SEE  MAJ.  JACK  JORDON) 

Mr.  Mike  Piercy  (703)  998-6660  (703)  998-0667 

Clay  Putman,  GPS  (703)  27 1-7700  (703)  27 1-8566 

Don  Rea,  MITRE  (703)  883-6249  drea@mitre.org 

Chunghye  Read  (703)  285-9236 

Robert  Reed,  Mike  Robinson  (703)  487-8024  (703)  487-8038 

Michael  Rybacki  (703)  607-3385  (703)  607-3381 

Richard  Schiller,  MITRE  (703)  883-3741  m23517@mwvm.mitre.org 

Steve  Shervais,CACI  (703)  875-2911  (703)  875-2904 

Ernie  Smart 

Jim  Stempeck  (719)  548-9704 

Walt  Swindell,  USA  (913)  684-3030  swindelw@tracer.army.mil 

Peter  Valentine, USA  (602)  538-4976  (603)  538-4973  valentin@huachuca- 

emh7.army.mil 

Massey  Valentine,  COLSA 

James  Vernon  (703)  697-3635 

LTC  J.  Weidewitsch  (703)  998-0660  (703)  998-0667 

Ken  Wimmer,  SAIC/DMSO  (703)  379-3770  (703)  379-3778  kwimmer@dgis. 

dtic.dla.mil 

Rob  Wright,  RCI  (407)  282-145 1  (407)  658-954 1 

S.  Youngblood, JHU  (301)  953-5000  (301)  953-6910  x4000 

simone@aplcomm.jhuapl.edu 
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PRESENTERS  THAT  ARE  NOT  MEMBERS 
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blake@spso.gsfc.nasa.gov 
(601)  688-5332 
(813) 830-4919 
(703) 285-5403 
(703) 640-3714 


Mr.  Hart  DeGrafft 
Ms.  Debbie  Blake 
Mr.  Alan  Chappel 
LTC  Rayford  Eubanks 
Mr.  Bill  Greyard 
Mr.  Frank  Hoffman 
Maj.  Kent  Johnson 
Mr.  Farid  Mamaghani 
Mrs.  Bunnie  Smith 
Nancy  Thatcher 
Mr.  John  Tieso 
Mr.  Jeff  Turner 
Mr.  Gene  Wiehagen 


(703)  696-1906  or 
(202)  863-9960 
(601)  688-4892 
(813) 830-6210 
(703) 285-5375 
(703) 640-3714 
(513) 255-0549 
(206) 957-3264 
(703) 746-7222 
(703)  746-7190 
(703) 746-7938 
(703) 355-3838 
(407) 380-4363 


farid@charm.isi.edu 


(703) 746-7396 
(703) 355-3176 
(407) 380-4258 


ATTENDEES  THAT  ARE  NOT  MEMBERS 


Jim  Calvin  (LOREL)  (617)  873-3603  (617)  873-2099  calvin@camb-lads.lorel.com 
Mr.  Jim  Davidson  (DoD) 

Mr.  George  Endicott  (DoD) 

Kim  Gebhardt,  DMA  (703)  285-9383 


Ms.  Brooke  Guthrie 
J.Lencozowski,  DMA 
Capt  Jerry  McWhorter 
Col  A1  Moore,  DMA 
Peter  Robison,  DMA 
Eleanor  Schroeder 
Kent  Sieverding 
Opal  Stroup,  DMA 


(301) 763-1390 
(703)  285-9783 
513-255-0549 
(703) 285-9344 
(703) 285-9383 
(601)  688-4270 
(513) 429-6158 
(703) 285-9344 


(301) 763-1359 


(703) 285-9397 
(601) 688-5701 
(703) 285-9397 


3.  SUMMARY  OF  ISSUES,  WORK-TO-DO,  TOPICS  FOR  NEXT 
MEETING 


(1)  Topics  suggested  for  the  next  I/DB: 

DTIC  brief:  Bob  Bishop - TECNET  update:  George  Hurlburt  Theater 

Battle  Management  C4I  (architecture  automation  "example  of  process  and 
data  modeling”:  Captain  David  Hess  Update  on  Security  CONOPS  for  IC 
Catalog:  Dr.  John  Griffiths  Merits/problems  with  data  modeling:  DMSO 
report  on  focus  calls  and  funded  projects  Session  on  sources  of  data 

(2)  DMSO  Data  Administration  Survey  contact  Dr.  Chien  Huo  at 
huo@dmso.dtic.dla.mil  or  703-487-8036,  or  AUTOVON  364-8036. 

(3)  New  reference  documents:  Guidance  for  Definition  of  Managed  Objects 
ISO  10165-2  (Robinson) 
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(4)  Iris  Kameny  action  item:  coordinate  with  Sid  Kissin  on  visit  to  NSA  to 
discuss  intelligence  data  for  M&S  and  intel  models 


People  signed  up: 
Chris  Landauer 
Bill  Burch 
Rich  Moore 
Richard  Kruger 
Martin  Katz 
Mike  Lightner 
Mike  Seiverding 
James  Hines 


cal@aero.org 

703-824-0100 

moore@orll.orlando.loral.com 
rkruger@spms .  saic .  com 
703-749-5414,  katz@coeic.saic.com 
DSN  785-4429 
513-429-5580/6158 
703-556-1299,  fax  703-556-1174 


(5)  Chien  Huo/Iris  Kameny  action  item:  coordinate  visit  to  Bunnie  Smith  to 
discuss  M&S  data  administration  issues 


Chris  Landauer 
Clay  Putman, 
Bob  Bishop 
Mike  Rybacki 
Luci  Haddad 


703-271-7700 

703-274-7661 

703-607-3385 

407-282-1451 


(6)  Be  sure  to  put  the  MORS  Mini-Symposium  on  “Modeling  and  Simulation 
Data  Issues”,  Nov.  16-18,  on  your  calendar.  Contact  Howard  Haeker  913- 
682-3030,  or  Natalie  Addison  at  the  MORS  office  703-751-7290  for  more 
information. 


(7)  Note  that  the  next  I/DB  meeting  will  probably  be  held  in  January  due  to  the 
MORS  meeting  in  Nov.  and  the  holiday  season. 

(8)  Suggested  working  groups  that  could  be  formed  from  I/DB  members  (1) 
IDEF  modeling  (2)  Exploring  data  standards  in  FDAD  area  such  as  C2  (3) 
Investigating  types  of  data  (Marty  Katz  volunteered) 

—  metadata 

—  empirical  data 

—  planning  factors 

—  rules  of  engagement 

—  tactics 

(4)  Dealing  with  the  area  of  data  reconciliation 

(5)  Challenging  the  data  standardization  process 

—  alternatives 

—  goal?  where  are  we  going? 

(6)  Exploring  characteristics/types  of  models  and  the  metadata  needed  to 
describe  them  (this  is  needed  to  make  an  effective  directory  of  models  and  to 
support  reuse  repository):  Farid  Mamaghani  was  very  interested  in  this 
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4.  UPDATE  ON  DMSO  HAPPENINGS 

(1)  Welcome  and  DMSO  Update:  LTC  Jerry  Wiedewitsch 

LTC  Jerry  Wiedewitsch,  the  DMSO  Deputy  Director,  opened  the  meeting 
with  a  brief  on  the  DMSO.  Navy  Captain  Bruce  McClure  is  the  new  DMSO 
Director.  The  DMSO  vision  is  to  create  realistic,  recyclable,  and  complex 
“worlds”  through  modeling  and  simulation  (M&S)  to  improve  how  we  do 
everything:  readiness  and  warfighting,  design  and  prototyping,  education  and 
re- training,  and  emergency  preparedness.  The  DMSO  mission  is  to 
strengthen  the  use  of  M&S  in  joint  education,  training  and  military 
operations;  research  and  development;  test  and  evaluation;  analysis;  and 
production  and  logistics.  Important  areas  to  be  supported  by  current  M&S 
activities  are  joint  combined  arms  and  the  JWC.  Dr.  Anita  Jones,  who  chairs 
the  EXCIMS,  is  looking  beyond  use  of  M&S  in  support  of  readiness  to  its  use 
by  the  acquisition  community  (who  have  expressed  a  lack  of  confidence  in  its 
use).  DMSO  working  with  OTA  and  OSTP  is  contributing  to  technology 
transfer  through  exploring  and  supporting  the  dual  use  of  M&S  in  K-12 
education  in  the  DoD  Dependent  Schools  (DoDDS)  as  well  as  for  militaiy 
education.  The  DMSO  FY93  Infrastructure  Task  Force’s  mission  is  to 
determine  what  infrastructure  building  blocks  need  to  be  put  in  place  and 
what  are  the  technology  gaps  that  need  to  be  filled  in.  The  DMSO  FY94  call 
for  proposals  is  focused  in  4  areas:  M&S  components,  M&S  common  system 
support,  M&S  interoperability,  and  M&S  community  awareness.  A  new  M&S 
industry  steering  group  has  been  formed  whose  subgroups  are  all  chaired  by 
people  from  industry  and  academia. 

(2)  Introduction  to  Dr.  Chien  Huo  and  an  overview  of  the  JIEO  M&S 
support  activities:  Iris  Kameny  and  Dr.  Chien  Huo 

Iris  Kameny  introduced  Dr.  Huo  who  will  be  joining  her  as  a  co-leader  of  the 
I/DB  Task  Group.  Iris  will  continue  focusing  on  issues  in  complex  data  and 
data  verification,  validation,  and  certification  (W&C)  while  Chien  will 
concentrate  on  M&S  data  administration  issues  with  MITRE  aid.  Both  will 
support  the  I/DB  task  group,  coordinate  I/DB  activities  with  the  new  DMSO 
supported  Information  Analysis  Center  (IAC)  and  maintain  the  I/DB  part  of 
the  DMSO  Information  System.  Chien  described  the  Joint  Interoperability 
and  Engineering  Organization  (JIEO)  Center  for  Standards  (CFS)  to  which 
he  belongs  and  its  program  support  for  DMSO  in  S&T  Thrust  #6  “Synthetic 
Environments”,  the  DMSO  Information  System,  standards  support  for  DIS, 
and  his  new  role  in  data  administration  for  M&S.  He  discussed  the  DMSO 
data  administration/standardization  program  objectives,  his  responsibilities 
and  approach  in  establishing  a  framework  for  the  data  administration 
program,  interacting  with  key  customers  such  as  STRICOM  and  DIS,  and 
establishing  and  prioritizing  customer  requirements  and  support  for  data- 
related  projects.  By  September  30,  he  plans  to  have  an  initial  DA  Concept  of 
Operations,  analysis  of  the  DMSO  DA  survey,  and  an  evaluation  of  the  utility 
and  expandability  of  the  Defense  Data  Repository  System. 
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Chien  distributed  a  “DMSO  Data  Administration  Survey”  which  you  are  all 
urged  to  fill  out.  The  information  gathered  will  facilitate  building  consensus 
and  cooperation  among  the  M&S  community  on  the  definition  and 
implementation  of  the  DA  program. 

(3)  Update  on  DMSO  Information  System:  Mr.  Ken  Wimmer  and  I/DB 
Partition:  Iris  Kameny 

Ken  announced  that  the  DMSO  Information  System  is  finally  up  and  running 
and  distributed  membership  forms  for  all  to  join  and  become  users.  The 
system  contains  many  DMSO  documents  in  electronic  form,  organizations 
and  POCs,  several  M&S  catalogs  and  more  to  come  later.  If  you  haven’t 
joined,  you  can  get  information  by  sending  email  to 
comments@dmso.dtic.dla.mil  or  by  calling  Ken  Wimmer  at  703-379-3770. 
Through  the  top  DMSO  Information  System  menu,  I/DB  members  can  call  up 
a  menu  of  I/DB  relevant  material  including  an  acronym  list,  definitions 
relevant  to  data,  a  document  reference  list  relevant  to  data,  interest  areas  of 
I/DB  members,  I/DB  membership  list,  agenda  for  the  next  I/DB  meeting, 
calendar  for  I/DB,  and  past  meeting  notes. 

(4)  M&S  Information  Analysis  Center:  Mr.  Ernie  Smart 

The  Tactical  Warfare  Simulation  and  Technology  Information  Analysis 
Center  (TWSTLAC)  is  sponsored  by  DMSO  and  jointly  operated  by  the 
University  of  Central  Florida’s  Institute  for  Simulation  and  Training  (1ST)  for 
DIS  related  M&S  projects  and  by  Batteile  for  tactical  warfare  projects.  The 
heart  of  the  TWSTLAC  will  be  access  to  databases  containing  thousands  of 
documents,  pictures,  and  other  material  dealing  with  the  technologies  and 
research  involved  in  live,  constructive,  and  virtual  M&S.  It  is  intended  to 
become  DoD’s  primary  agent  for  M&S  information  and  to  provide  short  term 
support  on  urgent  matters  such  as  reports,  studies,  benchmarking, 
identification  of  appropriate  data,  and  creation  of  unique  databases,  catalogs 
and  documents.  Its  support  activities  include:  primary  research;  supporting 
use  of  standardized  M&S;  promoting  standardized  processes  for  collection, 
analysis,  etc.  of  test  data;  conducting  M&S  seminars,  symposia,  and 
workshops;  conducting  methodological  feasibility  testing;  performing 
technical  area  tasks  for  tailored  customer  needs;  and  providing  technical 
consultation  on  M&S  issues.  Its  information  clearinghouse  activities  include: 
collection  and  management  of  relevant  reference  information;  identification  of 
knowledge  gaps;  putting  selected  data  in  electronic  form;  informing 
customers  of  information  via  catalogs,  newsletters,  etc.,  providing  single 
entry  point  for  new  customers;  developing  and  maintaining  M&S  tutorials; 
answering  questions  and  conducting  searches;  and  operating  an  electronic 
bulletin  board. 

5.  REPORTS  FROM  NEW  M&S  ORGANIZATIONS 

(1)  New  Air  Force  M&S  Organization:  Dr.  James  Vernon  (AF/XOMT) 
Captain  David  Hess:  TBM  C4I  Architecture 


1003 


The  Air  Force  Director  of  Modeling,  Simulation  and  Analysis  (USAF/XOM)  is 
Brig  Gen  Campbell;  the  office  is  under  Deputy  Chief  of  Staff  Plans  and 
Operations  (USAF/XO)  which  is  under  HQ/USAF.  The  XOM  mission  is  to 
strengthen  operational  readiness  by  providing  direct  support  to  the 
warfighter  for  USAF  modeling,  simulation,  and  analysis  that  involve  plans, 
operations,  and  operational  requirements.  XOM  is  the  AF  focal  point  for 
M&S  and  objectives  include  development  of  analytical  tools  and  procedures  to 
support  cost  effective  decisions;  insight  into  force  structure  deficiencies; 
providing  education  and  training;  and  demonstrating  the  capability  and  use 
of  air  power.  XOM  consists  of  three  divisions:  Warfighting  Support  (XOMW), 
Evaluation  Support  (XOME),  and  Technical  Support  (XOMT). 

Captain  Hess  works  for  Air  Combat  Command  and  is  concerned  with  Theater 
Battle  Management  C4I  architecture.  They  are  participating  in  the  joint 
Tactical  Battle  Management  (TBM)  Global  Operations  Steering  Group 
(GOSP)  which  is  an  initiative  to  improve  theater  C4I  by  applying  CIM 
methodology  which  includes  quality  improvement  teams,  identifying  and 
applying  technology,  migration  paths  to  interoperability  and  standards,  and 
rapid  prototyping  and  testbeds.  The  TBM  C4I  Architecture  project 
requirements  include:  central  control  and  configuration  management, 
distributed  data  gathering,  data  ownership,  central  repository,  and  support 
for  dynamic  analysis.  They  are  using  Zackman’s  architecture  to  define  the 
TBM  C4I  Architecture  to  express  what,  how,  where,  who,  when,  why.  The 
1993  program  scope  is  deployed  sustained  theater  with  focus  on  the  Air 
Tasking  Order  (ATO)  process  analysis  and  build  using  top-level  models  for 
CRC,  ASOC,  AWACS,  JSTARS,  ABCCC,  TACP,  FACP,  and  C-130  wing. 

They  are  building  detailed  theater  information  flows  between  all  AF  OPFACs 
and  indepth  as-is  and  to-be  static  and  dynamic  models  for  force-level  Air 
Operations  Center  and  Wing  Operations  Center.  They  ultimately  want  to  be 
able  to  link  their  architecture  to  the  ARPA  Warbreaker  architecture  by 
providing  a  process  model  and  simulation  tool  so  that,  for  example,  the 
Warbreaker  project  will  know  what  ABCCC  does  by  looking  at  the  process 
model  through  the  simulation  tool.  For  the  Air  Ops  data  model  kick-start 
project  sponsored  by  DISA/JIEO/TBC  and  J6I,  they  are  mapping  info  from 
activity  models  to  or  3  data  model.  They  are  using  subject  matter  experts 
(SMEs)  from  all  services  to  define  what  data  is  used,  standardize  data 
descriptions,  and  determine  the  relationship  of  one  piece  of  data  to  another. 

(2)  Intelligence  Community  M&S  Coordinating  Group  and 
Intelligence  Models:  Dr.  Sid  Kissin 

The  IC  M&S  Coordinating  Group  was  established  in  October  1992  to  be  a 
focal  point  for  M&S  coordination  within  the  IC  and  to  work  with  DoD.  Its 
proposed  responsibilities  are  to:  provide  information  about  M&S  applications, 
support  the  DoD  Master  Plan  and  Investment  Plan,  explore  joint  or 
cooperative  developments,  and  to  establish  W&A  policies,  procedures  and 
guidelines.  They  have  established  four  working  groups:  symposium  (their 
next  Symposium  on  Intelligence  Applications  of  Modeling  and  Simulation  will 
be  held  November  16-17  at  NSA),  M&S  catalog,  community  relations,  and 
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standards  and  protocols.  Dr.  Kissin  represents  the  IC  M&S  Coordinating 
Group  on  the  USD(A&T)  EXCIMS  for  M&S. 

A  major  benefit  in  use  of  M&S  in  IC  is  to  take  care  of  the  seams  that  occur 
because  of  non-overlapping  charters/missions  of  IC  organizations.  ARPA  will 
be  doing  this  for  Warbreaker  which  will  include  simulation  of  intel.  An 
example  of  cost  savings  that  could  be  accomplished  through  an  M&S 
clearinghouse  would  be  that  instead  of  each  service  maintaining  a  facility 
model  there  could  be  one  general  purpose  facility  model  for  which  each 
service  could  add  its  special  enhancements. 

The  IC  M&S  Coordinating  Group  was  established  in  anticipation  of  a 
DDR&E  directive  which  will  call  on  all  DoD  organizations  to  establish  a 
central  focus  for  M&S  and  be  responsible  for  accrediting  models  within  their 
focus  area.  There  were  questions  from  the  audience  about: 

(a)  Models  such  as  TACWAR  include  an  intelligence  collection  asset  and 
the  new  directive  would  require  that  the  model  be  accredited  by  the  IC 
as  valid.  However,  without  a  policy  or  set  of  standards  and  procedures, 
it  appears  possible  for  the  IC  to  refuse  to  validate  a  model  and  not 
necessarily  explain  how  to  make  it  valid.  Then  there  would  be  a  sort  of 
limbo,  the  model  is  invalid  for  use  but  there  is  no  clear  way  to  make  it 
valid.  Kissin’s  reply  was  that  the  accreditation  responsibility  was  being 
put  upon  them  by  DoD  without  adequate  policies  and  guidelines  to 
prevent  this  from  happening. 

(b)  Availability  of  intelligence  data  for  tactical  models:  so  far  the  IC  has 
avoided  sharing  of  data  with  the  tactical  world  but  Kissin  believes  they 
will  have  to  start  doing  this,  (my  comment:  it  would  appear  that  they 
would  also  have  to  certify  that  the  intel  data  was  verified  and  valid  in 
order  to  accredit  the  model.) 

6.  DATA  SECURITY 

(1)  Security  CONOPS  for  Intelligence  Community  Catalog  of  M&S: 
Dr.  John  Griffiths  (IC  M&S  Coordinating  Group) 

The  IC  Coordinating  Group  wants  to  build  an  M&S  catalog  similar  to  those 
built  by  J8,  the  Army  and  the  Navy.  A  lot  of  intel  models  already  exist  in  the 
Army  and  Navy  catalogs.  The  IC  will  need  to  control  the  data  going  into  the 
catalog  because  of  the  security  risks  of  data  aggregation — a  large  amount  of 
unclassified  data  may  become  sensitive  because  more  knowledge  can  be 
inferred  from  the  aggregated  data  than  from  the  data  in  each  contributing 
source  considered  alone.  Because  of  the  data  aggregation  problem  and 
because  the  IC  community  will  have  classified  information  about  some  of  its 
models,  the  IC  catalog  will  be  composed  of  two  parts:  unclassified  and 
classified.  The  unclassified  catalog  will  be  able  to  co-exist  on  the  DMSO 
Information  System  while  the  classified  part  will  be  a  separate  IC  catalog. 
Because  users  in  the  IC  do  not  have  access  to  the  unclassified  internet,  the  IC 
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will  also  need  to  migrate  the  existing  Army,  Navy,  and  J8  catalogs  onto  a 
classified  IC  net.  Access  to  the  classified  catalog,  for  now,  will  be  by  hard 
copy  but  in  the  future  may  be  part  of  a  secure  network  using  electronic 
transfer.  For  now,  there  will  be  POCs  throughout  the  community  that  will 
have  copies  of  the  classified  catalog  that  exists  in  a  central  repository,  and 
they  will  be  responsible  to  determine  a  user’s  need  to  know  and  if  established 
will  furnish  him/her  the  catalog  information.  Another  point  is  that  for 
classified  models,  they  will  try  to  have  scant  information  in  the  unclassified 
catalog  that  will  indicate  the  general  nature  of  the  model  and  a  point  of 
contact. 

(2)  Defense  Information  System  Security  Program  (DISSP):  Mr.  Hart 
DeGrafft 

The  DISSP  organization  started  in  1990  and  recently  became  a  part  of  the 
JIEO  Center  for  Information  Systems  Security.  It  is  jointly  staffed  with 
people  from  DISA  and  NSA.  The  major  missions  of  the  center  are:  DISSP, 
multi-level  security,  and  operational  INFOSEC.  There  are  six  directorates  in 
DISSP: 

(1)  Policy,  plans,  programs  and  resource  management:  supports  C3I  in 
policy  development;  coordinates  information  systems  security  studies 
requested  by  OSD;  coordinates  NSA  and  NIST  security  initiatives  to  ensure 
consistency;  provides  funding  to  non-DoD  government  security  activities; 
recommends  development  of  new  technology;  provides  database  of  solutions 
that  services  and  agencies  can  use  to  satisfy  security  requirements;  performs 
planning,  programming  and  budgeting  for  DISSP;  supports  OSD  in  DoD 
INFOSEC  program  fiscal  review,  project  monitoring,  etc. 

(2)  Evaluation,  certification,  and  accreditation:  develops  DoD  wide 
certification  and  accreditation  standards,  can  reach  into  NSA  security  center 
for  support  if  needed.  Reviews  service  and  agency  policy  and  procedure 
documents  to  correct  conflicting  policies  and  oversee  security  aspects  of 
standards  implementation  and  tests  to  validate  that  security  requirements 
have  been  met.  Supporting  about  50-60  programs  in  this  way. 

(3)  Security  products:  with  respect  to  programs  for  which  DISA  is 
responsible:  will  establish  a  database  of  INFOSEC  R&D  programs,  will 
establish  a  program  to  solicit  requirements  for  INFOSEC  products  (look  to  fill 
in  voids);  will  establish  program  of  fiscal  support  to  INFOSEC  programs; 
assures  INFOSEC  product  availability;  acquires  and  deploys  security 
products;  assists  OSD  in  designing  and  implementing  tech  transfer  program 
in  security  products  and  technology. 

(4)  INFOSEC  professionalism:  will  establish  career  path  for  INFOSEC 
in  DoD  and  military,  develops  program  and  standard  courses  for  INFOSEC 
training,  provides  symposiums  for  DoD  information  systems  security; 
coordinates  comprehensive  INFOSEC  conference  and  awareness  programs. 

(5)  Security  architecture  and  engineering:  will  establish  DoD  AIS/T 
infrastructure  functional  and  technical  info  systems  security  requirements, 
develops  security  architectures,  transitions  plans  for  architecture 
implementation,  performs  configuration  management  of  DoD  ISS 
architecture  and  AIS/T  standards  in  coordination  with  DISA  Joint  Center  for 
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Standards.  This  group  is  located  at  NSA  and  is  writing  transition  plan  for 
legacy  systems. 

(6)  Countermeasures:  will  establish  automated  info  systems  security 
incident  support  team  (ASSIST),  will  establish  vulnerabilities  analysis  and 
assistance  program  to  assess  how  penetration  resistant  your  system  is,  will 
perform  INFOSEC  threat  assessment  and  share  with  intel  organizations,  will 
establish  program  to  incorporate  INFOSEC  countermeasures  in  DoD 
architectures  (e.g.,  intrusion  detection,  virus  eradication). 

Questions: 

Dan  Hogg:  INGRES/Sun  has  mis  product  in  pre-beta  test,  what  happens  if 
he  uses  it  in  the  OASIS  system,  what  are  the  implications  wrt  his 
applications?  ANSWER:  NSA  is  providing  security  profiles  to  be  able  to  take 
a  system  and  evaluate  it.  These  will  be  available  for  a  combination  of 
products  but  if  your  combination  isn’t  addressed,  then  put  it  on  the  list.  They 
will  facilitate  what  they  can. 

Question  about  availability  of  tools  to  aid  in  security  assessment  and 
evaluation  of  systems.  ANSWER:  DISSP  can  point  people  to  those  who  have 
such  tools  but  are  not  doing  much  tool  work  themselves.  However  they  can 
help  you  formulate  your  requirements  and  then  see  if  there  is  an  existing  tool 
or  one  under  development. 
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7.  DATA  ADMINISTRATION,  STANDARDIZATION  AND  MODELING 
ACTIVITIES 

(1)  DoD  Enterprise  Model:  Mrs.  Bunnie  Smith  (ODASD(IS))  (email: 
smithb@pentagon-hqda.dss.army.mil) 

Bunnie  Smith  briefed  the  DoD  Enterprise  Model  (viewgraphs  of  which  are 
available  from  CIM).  She  came  into  CIM  in  summer  91  and  looked  for  a  plan 
and  picture  without  finding  one.  GM  would  have  had  an  overall  view  of  itself 
before  embarking  on  a  CIM  effort.  There  was  a  need  to  establish  a  corporate 
goal  of  addressing  the  joint  good  for  the  corporation.  CIM  goals  are  to 
establish  a  common  view  of  the  corporation  and  a  common  language  and  to 
establish  functional  direction.  They  have  now  put  information  management 
(IM)  infrastructure  into  the  business  operations.  The  key  to  IM  integrity  is 
data,  not  just  with  respect  as  to  how  it  is  used  in  the  machine  but  why  people 
use  it.  Data  describes  the  “rules”  of  the  process  and  the  links  among  all 
processes. 

They  will  be  bringing  the  ATCCIS  Generic  Hub  Data  Model  together  with  the 
DoD  Enterprise  Data  Model  which  they  have  adjusted  to  add  entities  such  as 
activity.  They  have  linked  the  strategic  entities  from  the  Enterprise  Model 
down  to  the  ground  model  and  also  want  to  do  the  same  with  the  air  model. 

After  ODS,  there  was  no  longer  separate  accounting  for  deployed  forces  vs 
CONUS  forces  and  systems,  these  are  both  integrated  in  the  FYDP.  These 
are  now  included  in  “provide  capabilities”  rather  than  in  “employ  forces”. 

CIM  is  directed  toward  “acquire  assets”  and  “provide  capabilities”.  The 
custom  is  to  “employ  forces”.  One  needs  to  work  backward  with  customers  to 
change  direction  from  employing  forces: 

direction<--assets<--capabilities<~employ  forces 

In  as-is  modeling,  there  are  two  communities:  the  Joint  Staff  and  CINCS  do 
this  from  operational  plans,  and  the  military  departments  do  this  from  the 
developed  program  and  budget. 

They  have  been  asked  to  pull  out  “A42  Provide  Operational  Intelligence”  from 
the  Enterprise  Model  to  be  separate  from  “Employ  Forces'.  The  Joint  Staff 
will  also  rework  “A43  Conduct  Operations.”  What  won  out  with  90% 
customer  agreement  was  “conduct  intra-inter  government  operations”.  This 
would  serve  to  cover  civilian  disasters  like  hurricane  Andrew  cleanup  and 
support  modeling  of  organizations  like  FEMA  which  is  split  into  traditional 
civil  defense  and  natural  disasters  with  incompatibilities  between  the  two, 
e.g.,  in  accommodating  different  communication  systems. 

A  data  model  can’t  be  built  on  its  own,  the  Enterprise  Model  is  built  with  a 
goal  to  support  the  corporate  good.  Data  approach: 
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models-->architecture-->SDEs-->database 

She  believes  that  almost  all  concepts  are  strategic  level  entities. 

By  September  1,  the  Enterprise  Model  and  ATCCIS  will  be  put  together  and 
a  keybased  data  model  produced.  She  asked  what  we  thought  were  the 
categories  needed  to  break  the  model  down  further  toward  the  bottom  data 
definitions?  (My  comment:  we  think  this  taxonomy  has  been  missing  from  the 
start  and  are  working  on  developing  it  from  the  bottom-up  because  we  are  not 
sure  you  can  get  there  only  from  the  top-down.)  Bunnie  said  to  call  her  when 
you  are  developing  bucket  breakdown  structure — and  report  on  pieces  of  the 
undefined  taxonomy.  They  and  we  are  also  concerned  with  a  way  to  develop 
data  models  that  supports  multiple  views.  She  agreed  that  we  also  need  to  be 
able  to  state  business  rules  in  a  machine  processable  way  but  this  is  not 
currently  supported  in  the  DDRS. 

(2)  Update  on  DoD  Data  Administration  Program:  Ms.  Lynn 
Henderson  (DAPMO) 

Center  for  Information  Management  (CIM)  has  responsibility  for  definition, 
organization,  supervision  and  protection  of  data  within  an  enterprise  or 
organization  (from  DoDD  8320.1).  CIM’s  purpose  is  to  provide  effective, 
economic  acquisition,  and  use  of  accurate,  timely  and  shareable  data  to 
enhance  mission  performance  and  system  interoperability  (from  DoD  DASP 
FY92).  There  are  two  classes  of  beneficiaries:  decision  makers  (end-users: 
e.g.,  warfighters,  CINCs,  SecDef)  and  systems  builders.  For  the 
decisionmaker,  die  right  data  needs  to  get  to  the  right  person  at  the  right 
time  for  enhanced  performance  and  at  reduced  cost.  Benefits  for  the  system 
builder  are:  controlled  redundancy,  expedition  of  information  system 
development  and  maintenance,  and  facilitation  of  data  reuse  and  exchange — 
results  in  cost  savings. 

CIM  initiative  context:  DoD  missions,  policies,  strategies,  tactics,  goals, 
objectives,  critical  success  factors,  doctrine,  laws,  directives,  regulations, 
commander’s  guidance  and  operation  orders  feed  into  the  processes  of 
building  activity/process  models  and  building  data  models.  The  data  model 
results  in  coordination  and  registration  of  DoD  standard  data  which  is 
managed  in  a  DoD  data  repository.  Iterative  feedback  occurs  between 
process  and  data  modeling  to  develop  models  that  are  used  to  engineer  the 
information  system  software  and  data  (data  standards  from  the  DoD  data 
repository).  This  results  in  interoperable/integrated  systems  that  can  share 
data. 

The  CIM  policies,  procedures,  etc.  are  described  in  the  DoD  8000  series.  DoD 
8020.1  describes  the  business  process.  DoD  8120.1  describes  the  information 
system  process  design  and  development,  and  DoD  8320.1  the  DoD  data 
administration  process  (including  the  DoD  Data  Administrator  (DA), 
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Functional  Data  Administrator  (FDAd)  and  Component  Data  Administrator 
(CDAd)  roles  and  process). 

Where  are  they? 

—  Strategic  planning:  doing  an  annual  update  to  plan  with  FDAd  and 
CDAd  participation  and  eight  year  strategic  plan  is  in  final  draft 
form. 

—  Policies,  procedures,  and  standards:  DoDD  8320.1  “DoD  Data 
Administration”  issued  Sept.  1991,  DoD  8320. 1-M  “DoD  Data 
Administration  Procedures  Manual”  in  final  form,  DOD  8320. 1-M- 1 
on  data  element  standardization  is  approved,  DoD  8320.1-M-x  on 
modelsand  model  standardization  is  under  development,  and  other 
DoD  8320.1-M-x  documents  on  DB  administration,  quality,  and 
security  are  under  development. 

—  Education,  training  and  consultation:  have  established  executive  and 
management-level  seminars,  classroom  training  modules,  remote 
training  capability,  and  computer-based  training.  Trained  over  2,000 
people  during  past  year. 

—  DoD  data  model  and  architecture:  Developed  the  DoD  Enterprise 
Data  Model  and  are  looking  to  integrate  it  with  the  ATCCIS  Generic 
Hub  data  model.  Right  now  there  is  no  way  to  bridge  the  DoD 
Enterprise  model  from  the  top  down  with  models  from  the  bottom-up. 
To  help  address  this  problem  they  will  be  allowing  interim  data 
models  developed  from  the  bottom-up.  Beckie  Harris’  CIM  group  is 
also  addressing  complex  data  standards. 

One  problem  is  that  the  functional  areas  don’t  fit  the  data  buckets  of 
the  Enterprise  Model.  Recognized  data  entities  will  have  stewards  and 
the  stewards  will  coordinate  on  proposed  data  entities.  When  we  begin 
to  develop  a  data  model,  we  need  to  let  the  functional  area  stewards 
know  we  are  doing  so.  Question:  how  do  we  know  who  the  functional 
area  data  stewards  are?  (or  how  do  the  Component  M&S  offices  learn 
who  the  data  stewards  are?  For  if  they  know,  then  M&S  projects  could 
coordinate  with  them.) 

—  Data  dictionary/repository:  defining  future  repositoiy  capabilities  and 
have  support  for  current  Defense  Data  Repository  System  (DDRS) 
(have  developed  user  manual,  access  procedures,  approval  process, 
IOC  dictionary  capability).  They  are  trying  to  establish  a  baseline  for 
all  DoD  repositories  that  exist  and  establish  the  DoD  repositoiy 
requirements  by  collecting  all  the  requirements  on  which  the 
different  repositories  were  based.  They  are  not  forcing  use  of  the 
DDRS,  but  need  to  know  about  all  repositories.  However,  all  data 
elements  (DE)  in  use  throughout  DoD  should  be  registered  in  the 
DoD  repository.  They  also  recognize  that  instance  data  has  to  have 
an  owner  that  is  a  responsible  party. 

—  Quality  assurance:  they  have  established  guidelines  and  assessments 
for  data  but  so  far  there  are  few  if  any  approved  DE  in  the  DDRS. 
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MY  COMMENT:  THE  NEW  INTERIM  DATA  STANDARD  APPROACH  (AS 
DESCRIBED  BELOW)  IS  VERY  IMPORTANT  TO  THE  DEVELOPMENT 
OF  M&S  DATA  ELEMENTS.  THE  NEW  M&S  FDAd  SHOULD  HAVE 
MORE  TO  SAY  ON  THIS  SUBJECT  IN  THE  FUTURE. 

DoD  Challenge:  they  have  been  told  by  developers  and  functional  customers 
that  more  rapid  development  of  standard  data  is  needed.  They  are  kicking  off 
an  accelerated  program  to  define  more  DEs  through  use  of  Interim  Data 
Standards  (IDS).  The  FDAds  will  assess  demand/risks,  select  and  enter 
IDSs,  and  develop  plans  to  merge  with  formal  data  standards.  The  data 
architecture  people  will  use  cluster  analysis  to  scope,  focus,  validate  and 
refine  extensions  while  integrating  models  and  views  into  the  DoD  Data 
Model.  Constraints  on  IDSs  are:  (1)  FDAds  must  cross-functionally 
coordinate;  (2)  IDSs  will  be  placed  in  functional  partitions  of  DDRS;  and  (3) 
IDSs  will  be  used  until  Formal  Data  Standards  are  approved.  The  approach 
is  to  develop  IDSs  in  priority  areas  of  the  Enterprise  Model.  The  major 
change  is  for  a  DE  to  be  entered  unlinked  to  the  Enterprise  Model  and  then 
integrate  it  later. 

The  DAPMO  will  be  developing  a  starter  set  of  model-based  IDS  from  models 
already  submitted  to  the  DoD  DA,  and  will  circulate  these  for  cross-functional 
coordination.  DAPMO  provides  options  for  FDAds  to  designate  alternative 
sets  of  IDSs  based  on  their  model,  systems,  or  dictionary.  FDAds  with 
DAPMO  will  develop  a  plan  and  schedule  for  merging  IDSs  into  formal  data 
standards. 

Options  for  FDAds  developing  IDSs: 

(1)  Functional  model:  develop/identify  IDSs  for  its  own  data  based  on  its 
functioned  data  model  or  functional  subset  of  some  other  DoD  or 
external  model 

(2)  Systems  model:  develop/identify  IDSs  for  its  own  data  based  on  a 
logical  model  reverse  engineered  from  a  designated  migration  system. 

(3)  Scrubbed  dictionary:  develop/identify  IDSs  for  its  own  data  based  on 
functional  data  dictionary  DEs  scrubbed  to  minimize  data  redundancy, 
provide  clear  definitions  and  essential  metadata 

(3)  Report  on  IDEF  Users*  Group  meetings  and  issues:  Mr.  John 
Tieso  (OSASD(IS))  (No  viewgraphs  presented) 

There  are  three  things  to  report  on:  (1)  initiatives  about  activities;  (2)  where 
things  are  with  respect  to  guidance  and  handbooks;  and  (3)  where  the  IDEF 
users’  group  and  other  groups  are  with  respect  to  definition  of  a  common  tool 
set. 

The  M&S  community  needs  to  go  through  business  process  modeling  and 
identify  standard  data  which  can  be  simulated  and  finally  model  that  data  in 
a  data  model. 
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Concurrent  work  is  going  on  between  NIST  and  the  IDEF  Users’  Group  with 
respect  to  IDEFO  and  IDEF  IX.  The  objective  is  to  define  how  the  same  IDEF 
model  can  be  dealt  with  by  any  tool  set,  to  enable  moving  from  tool  to  tool  to 
deal  with  as-is  and  to-be  models.  Want  to  be  able  to  move  IDEF  models 
across  different  repository  systems. 

DoD  has  to  convince  vendors  to  adopt  common  definitions  to  make  it  easier  to 
move  models  to  and  from  repositories.  An  IDEF  interface  definition  language 
(IDL)  should  be  unveiled  in  October  which  if  used  by  vendors  developing 
information  management  toolsets  should  make  model  exchange  easier. 

A  FIPS  is  coming  out  in  three  weeks  that  includes  an  IDEF  IDL.  This  means 
that  ICASE  vendors  will  be  required  to  meet  the  IDL  standard  in  their 
toolsets.  Use  of  a  standard  should  support  model  movement  across  tools.  A 
contract  has  also  been  negotiated  between  NIST  and  the  IDEF  Users’  Group 
to  address  IDEF3  (dealing  with  time)  and  IDEF4  (dealing  with  object- 
oriented  databases).  IDEF4  should  allow  us  to  deal  with  legacy  systems  by 
making  objects  out  of  them. 

Tieso  has  also  been  involved  in  standards  for  groupware,  a  whole  series  of 
new  tools  that  will  dramatically  change  the  way  we  perform  functional 
process  improvement. 

There  is  a  big  gap  between  the  capabilities  of  an  operational  DBMS  and  the 
current  DDRS.  There  is  a  need  to  provide  users  with  common  sense  ways  to 
do  business  at  a  lower  cost.  CIM  is  looking  at  an  integrated  toolset  for  an 
“Intelligent  Repository”  to  replace  what  is  currently  called  the  DDRS.  This 
would  allow  one  to  easily  take  data  out  of  the  repository  and  use  it  in 
applications 

Finally,  vendors  are  realizing  that  CIM  is  real. 

(4)  Air  Mobility  Command  Information  Resources  Repository 
System:  Major  Doug  Hurd,  (AF/HQ/AMC/SCTI) 

The  AMC  4-star  has  called  for  a  single,  integrated  AMC  C2  system  for  the 
planning,  scheduling  and  execution  of  mobility  forces.  Users  don’t  care  where 
the  data  is  managed  just  so  long  as  they  can  access  it  when  they  need  it.  The 
AMC  future  C2  architecture  has  one  place  to  store  all  data,  all  applications 
access  the  same  database,  users  need  only  one  terminal  or  PC  to  access 
everything,  and  eventually  MLS  will  allow  users  to  traverse  between 
classification  levels. 

AMC  is  in  its  third  year  of  process  modeling  having  switched  to  IDEFO  tools 
and  modeling  discipline  about  a  year  ago.  Process  modeling  takes  a  long 
time.  Doug  showed  an  Aerial  Port  model  which  took  over  $350K  to  build. 
They  have  also  invested  resources  over  the  past  three  years  in  data 
standardization  and  are  working  with  AF  and  USTRANSCOM  to  nominate 
data  elements  to  the  DDRS. 
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They  feel  a  key  to  success  is  to  provide  a  capability  to  enable  meta¬ 
information  customers  access  to  whatever  data  they  need  to  conduct  analysis, 
overhaul  business  practices,  standardize  data,  or  build  integrated  systems. 
They  need  a  repository  system  that  can  support  all  kinds  of  metadata  about 
differing  types  of  information  assets  including  links  between  different  types 
of  metadata.  They  believe  that  centralization  will  help  them  control,  register, 
validate,  and  manage  all  of  this  metadata  as  well  as  help  in  designing 
auditing  capabilities  to  alert  them  to  possible  inconsistencies  in  the 
metadata. 

The  Repository  IOC  will  be  within  the  next  12-15  months.  The  effort  consists 
of  12  objectives  which  are  funded  and  of  low  technical  risk. 

(1)  Hardware:  Sim  2000  (CPU,  memory,  and  storage  can  be  expanded) 

(2)  Air  Force  Information  Resource  Dictionary  System  (AFIRDS): 
changed  to  implement  8320.1-M-l  data  element  descriptions,  and  are  testing 
a  remote  printing  capability  for  dial-in  and  DDN  users  (unlike  DDRS)  which 
should  be  available  by  September.  Also  working  toward  possible  merger  of 
AFIRDS  with  DDRs.  (To  that  end  are  lining  up  resources  for  conversion  to 
Ada.) 

(3)  Pilot  evaluations  of  tools:  need  to  bridge  gap  between  IDEFO  and 
final  delivery  of  C4  system  so  are  doing  joint  agency  pilot  tests  using  real 
AMC  data  and  models  as  input.  These  include:  CM,  ADAPT  tool  test  and 
IDEF3  sponsored  by  DDI,  and  Design  CPN. 

(4)  Meta-Information  Linkage:  overall  repository  management  system  is 
an  Infospan  product.  Looking  for  Infospan  assist  in  designing  number  of 
audit-like  programs  to  detect  metadata  inconsistencies  between  IDEFO  and 
IDEF1X  models  and  in  future  may  look  at  intelligent  cross  audits. 

(5)  Process  “To-Be”  Analysis:  augmenting  going  from  as-is  to  to-be 
models  by  using  simulation  tools  and  activity-based  costing  in  deriving 
desired  implementation  target  plans  and  strategies. 

(6)  Data  Modeling:  ensure  consistency  between  system  models  and 
approved  command  level  logical  data  model  and  ensure  that  all  command 
efforts  reflect  latest  available  data  from  DoD  data  standardization  process. 

(7)  Data  Element  Level  Processes:  begin  augmenting  process  modeling 
efforts  by  identifying  specific  data  items  from  forms,  computer  screens,  etc., 
which  are  input/output  from  decomposed  process  model  activities.  This  will 
enable  linking  business  process  to  data  model  and  to  SDE  metadata  in 
dictionary  as  well  as  providing  basis  for  design  of  specific  applications. 

(8)  1,000  Data  Elements:  continue  effort  to  create  command  level  SDEs 
to  meet  January  1994  start  date  for  AMC’s  transportation  systems 
modernization  project. 

(9)  Technical  Integration  Strategy  document:  identifies  technologies, 
methodologies,  tools  and  strategies  that  lead  to  integrated  supportable 
systems  and  how  these  will  work  together,  who  will  perform  the  activities, 
and  what  are  the  expected  outcomes. 

(10)  Repository  CONOPS:  user-level  concept  of  operations  for  the 
repository. 
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(11)  Repository  User  Manual:  to  describe  repository  mechanics  to  users 
and  at  same  time  provide  for  system  order  and  integrity  overall. 

(12)  Repository  Process  Models:  provide  a  process  model  of  the  entire 
operation  of  the  repository  with  a  view  of  capturing  how  they  are  executing 
systems  integration  end-to-end.  These  models  will  become  the  primary  tool 
for  analyzing  their  integration  process  and  for  planning  process  and 
repository  improvements  in  the  future. 

Future  directions 

—  “hot  key”  from  process  model,  to  message  read  by  activity,  to 
IDEF1X  entity  relation  chart  containing  data  element  in  r  lessage. 

—  “autoload”  meta-information  between  similar  tools  like  those  in  the 
IDEFO  family,  and  freely  upload  same  validated  information 
upward  toward  systems  integration  process. 

—  “meta-information  integration”:  need  to  piece  differing  types  of 
meta-information  together  to  produce  an  integrated  look  to 
processes,  models,  architectures,  and  data. 

(5)  ATCCIS  Battlefield  Generic  Hub  Data  Model:  Iris  Kameny  for 
Major  Matt  O’Hanlon  (NATO/ATCCIS) 

The  objective  of  the  ATCCIS  generic  hub  model  is  to  model  tactical  structured 
data  to  help  define  the  standard  data  elements  to  facilitate  interoperability 
between  ATCCIS  conformant  C2  information  systems  of  NATO  nations.  In 
May  1992,  the  ATCCIS  permanent  WG  accepted  use  of  IDEF  methodology  to 
support  activity  and  data  modeling.  They  decided  to  develop  as-is  process 
models  and  to-be  data  models.  The  process  models  are  to  show  current  data 
flows  and  where  possible,  message  formats,  and  will  be  used  to  validate  the 
data  models. 

The  generic  hub  data  model  describes  the  real  world  objects  and  happenings 
on  the  battlefield  as  high  level  entities  in  terms  of  their:  classes,  locations, 
activities,  capabilities  (actual,  expected,  and  required),  and  guidance.  Who? 
units,  formations,  personnel.  What?  material.  Where?  location,  geographies, 
C2  features.  When?  battlefield  dynamics.  Actions?  describes  actions  carried 
out  on  the  battlefield.  The  core  information  defined  in  the  hub  is  data  that  is 
common  to  all  subfunctional  areas.  The  hub  represents  a  common  agreed  to 
view  of  the  core  information  requirements,  and  provides  the  base  from  which 
each  subfunctional  area  (SBA)  can  provide  its  own  “spoke”  model.  The  SBA 
models  will  then  be  consistent  with  each  other  and  the  hub.  At  least  one 
subfunctional  area,  the  fire  support  area,  has  developed  a  full  data  model  as  a 
spoke  to  the  hub. 

Current  status  of  ATCCIS  Generic  Hub  Data  Model: 

NATO/ATCCIS:  VI. 0  released,  SFA’s  Fire  Support,  Communication,  and 
Barrier  Operations  under  final  review;  Air  Defense  and  Intelligence  SFAs 
begun.  U.S.:  adopted  by  JIEO  6/93  as  Core  C3  Data  Model;  adopted  by  USAF 
as  start-point  for  Air  Ops  Data  Model  as  part,  of  RCAS  Block  2B;  trial 
underway  to  integrate  Human  Resources  and  Force  Authorization  RCAS 
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Block  1  models  with  generic  hub;  and  is  under  negotiations  with  CIM  for  final 
integration  with  DoD  Enterprise  data  model. 

(6)  Update  on  C2  data  modeling  activities  at  JIEO:  LTC  Mike 
Robinson  (JIEO/CFS  Chief,  C3I  SPT  Div) 

There  were  three  tasks  identified  at  the  May  27  MCEB: 

—  to  publish  the  210  interim  C2  data  elements  derived  for  the  Joint 
Universal  Data  Interface  (JUDI)  from  JOTS,  STALLS,  and  AIS 

legacy/existing  systems 

—  to  propose  adoption  of  generic  hub  data  model 

—  to  submit  fire  support  extension  of  generic  hub  data  model 

On  15  July,  Dr.  Quinn  C3I(A&T),  C2  FDAd  held  C2  coordination  meeting  at 
which  it  was  decided: 

—  To  agree  on  publishing  the  210  interim  C2  data  elements  which  have 
been  described  in  conformance  with  8320  but  have  not  been  data 
modeled.  These  will  be  submitted  to  a  DoD  data  standardization 
acceleration  project  for  data  modeling  no  later  than  1  October.  They 
will  be  part  of  an  interim  core  starter  set  of  data  elements.  This  will 
require  coordination  of  data  stewardship  with  other  FDAds.  In  the 
long  term,  the  C2  FDAd  will  continue  with  the  formal  data 
standardization  process. 

—  To  agree  on  generic  hub  for  C2  data  model  when  integrated  with  DoD 
Enterprise  Data  Model.  They  will  continue  building  Air  Ops  model 
on  modified  generic  hub.  In  the  nearterm,  JIEO  focus  group  will 
integrate  the  C2  view  into  the  DoD  Enterprise  Model.  In  far  term 
will  continue  formal  DoD  standardization  process. 

JIEO  Recommendations  to  Services: 

—  210  C2  data  elements:  review  proposed  interim  data  elements  and 
send  results  to  JIEO  by  1  September,  and  consider  these  available  for 
use  in  new  acquisitions 

—  C2  data  modeling:  build  C2  models  on  C2  generic  hub  data  model, 
identify  current  modeling  activities  to  JIEO  no  later  than  1 
September  1993 

(7)  MORS  Mini-Symposium  on  M&S  Data  Issues  (Nov  16-18):  Mr. 
Howard  Haeker  (Army/TRAC) 

Objective  of  symposium:  to  explore  the  application  of  standards,  technology, 

procedures,  and  policy  to  simulation  data  and  its  management 

When:  16-18  November  1993 

Where:  Fairview  Park  Marriot,  Falls  Church  VA 

Announcement  and  Call  for  Papers:  Abstracts  due  to  chairs  by  31  August  93 
Price:  $150.00  government  and  $300  others 

POCs:  Howard  Haeker,  TRAC,  913-682-3030,  and  Natalie  Addison,  MORS 
office,  703-751-7290 

Working  groups:  Working  Group  1:  Verification,  Validation  and  Certification 
(Iris  Kameny,  Bill  Dunn,  Dale  Pace,  and  Simone  Youngblood) 
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Working  Group  2:  Complex  Data  (Roy  Reiss,  Steve  Shervais) 

Working  Group  3:  Standardization  of  Data  (Twyla  Courtot,  Bob  Molter) 
Working  Group  4:  Tools  and  Techniques  (Chien  Huo,  Len  Seligman) 

Working  Group  5:  Research  Issues  (Don  Hodge,  Charles  Herring) 

Working  Group  6:  Data  Suppliers  (Dan  Hogg,  Robert  Wright 

Speakers:  Walt  Hollis,  DUSA(OR)  Dr.  Jeremy  Kaplan,  Directory, 
JIEO/Center  for  Standards  CAPT  Bruce  McClure,  Director,  DMSO  Ed 
Fitzsimmons,  Special  Assistant  for  Education  and  Training,  OSTP  White 
House 

(8)  Update  on  complex  data  issues:  Iris  Kameny  (RAND) 

Goal  of  complex  data  task  is  to  develop  guidelines  for  data  modeling  and  data 
standards  for  syntactically  complex  data  (e.g.,  terrain  and  road  data),  and 
semantically  complex  data  (e.g.,  data  derived  in  complicated  way  such  as  PK 
and  PH).  To  recommend,  if  necessary,  extensions  to  data  modeling  and  data 
definition  standards  to  accommodate  complex  data. 

The  approach  is  to:  perform  a  few  small  pilot  studies  for  semantically  complex 
data  (the  first  to  be  TRAC  TADS  in  August);  do  the  same  for  syntactically 
complex  data;  convene  Complex  Data  Task  Force  to  collect  more  examples 
and  develop  taxonomy  of  complex  data  types;  identify  modeling  and 
standardization  issues  and  suggest  solutions;  present  to  I/DB  for  discussion 
and  review;  document  results  and  brief  widely. 

Results  of  an  initial  session  with  TRAC/TADS  were  presented. 

IDEF1X:  It  is  easy  and  seems  intuitive  to  subject  area  experts  to  model 
complex  data  elements  as  attributes  of  the  relationship  between  multiple 
entities.  These  relationships  between  two  or  more  entities  can  be  modeled 
using  the  IDEF1X  associative  entity  but  the  usage  is  different  than  that  of 
representing  a  many-to-many  relationship  between  two  entities,  which  is  the 
primary  use  of  an  associative  entity.  There  is  reason  to  question  whether  this 
new  usage  overloads  the  associate  entity  construct  and  will  be  more  confusing 
to  the  user.  We  found  a  need  to  represent  causal  relationships  between 
activities  (e.g.,  target  acquisition,  fire,  hit,  kill).  We  also  found  a  lack  in  the 
IDEF1X  implementations  in  capturing  in  machine  readable  form:  cardinality, 
entity  relationships,  activities  and  activity  relationships,  and  different 
conceptual  views  of  an  integrated  data  model. 

DoD  metadata  representation:  we  are  uncertain  as  to  how  to  name  data 
elements  that  result  from  the  relationship  between  multiple  independent 
entities  since  DoD  naming  rules  allow  only  the  use  of  one  prime  word  (entity) 
though  other  prime  words  may  be  used  as  modifiers.  This  means  that  the 
data  modeler  must  arbitrarily  select  one  entity  as  the  prime  word. 
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8.  ENVIRONMENTAL  DATA  MANAGEMENT  AND  DATA 
STANDARDS 

(1)  Navy  Oceanographic  and  Atmospheric  Master  Library  (OAML) 
and  data  standards:  Mr.  Alan  Chappel  (Navy) 

By  congressional  mandate,  the  Navy  is  responsible  for  the  Oceanography 
standards  which  includes  meteorology  (atmospheric),  oceanography  (and 
acoustics),  astrometry,  and  mapping,  charting  and  geodesy  (MC&G).  These 
are  exercised  through  the  Oceanographic  and  Atmospheric  Master  Library. 
All  on-scene  and  shore  based  acoustic  system  performance  products  and  the 
Geophysics  Fleet  Position  Library  (GFMPL)  will  use  the  standards  and  the 
standards  apply  to  both  models  and  databases. 

The  environmental  data  standards  and  structures  manual  will  include 
OAML:  data  model,  information  model,  security  model,  data  element 
dictionary,  and  database  structure  diagrams.  The  plan  of  action  includes: 
reviewing  and  correcting  data  element  names;  proposing  developmental  DE 
names  and  metadata  definitions;  developing  database  structure  diagrams; 
deconflicting  DEs  in  multiple  databases;  correcting  the  OAML  data  model; 
and  revising  the  data  standards  and  structures  manual. 

The  OAML  performs  configuration  management  of  CNO  standard 
environmental  models,  databases  and  documentation.  It  sits  between  the 
suppliers  (system  commands,  labs,  contractors)  and  operational  users 
(environmental  systems,  weapons  systems,  and  trainers).  There  is  a 
Software  Review  Board  (SRB)  and  a  Configuration  Control  Board  (CCB)  that 
oversee,  and  prioritize  activities.  The  briefing  included  lists  of  models, 
databases,  major  players,  and  a  distribution  list.  The  models  are  mostly 
coded  in  Fortran  and  C  and  mainly  take  observations  which  they  merge  with 
historical  data.  The  models  are  mainly  machine  independent  except  for  I/O 
routines  and  they  come  with  routines  for  I/O  testing.  They  will  be  adding 
upper  air  climatology  and  three  more  atmospheric  databases  next  year. 

Some  instance  databases  are  collected  by  the  oceanographic  office  for  use  by 
others  and  these  have  instance  types  in  the  library  and  are  updatable  by 
developers.  In  July  1993,  the  Naval  Warfare  Tactical  Database  (NWTDB) 
program  furnished  data  standards  using  IDEF1X  methodology  including 
identifying  data  entities  and  elements. 

In  the  future,  they  would  like  to  develop  databases  of  temporal  snapshots  and 
have  made  a  proposal  through  the  DMSO  focused  call  to  collect  datasets  over 
windows  of  time  and  geographic  areas  (CMR  Wes  Barton,  601-688-4892). 

Environmental  systems  issues  and  needs:  early  incorporation  of  end  user 
capabilities;  methods  and  constraints  of  model  validation  practices; 
verification  procedures  and  criteria;  documentation;  greater  degree  of 
standardization;  and  bounded,  well  defined  prototypes. 


1017 


Question  was  asked  wrt  data  about  cloud  cover  ANSWER:  there  has  been  a 
big  effort  over  the  past  year  for  the  Navy  and  Air  Force  to  cooperate  on  joint 
areas  and  standard  products  and  cloud  cover  is  one  of  these  areas  and  the  Air 
Force  data  will  be  included  in  their  studies. 

(2)  EOSDIS  Overview:  Ms.  Debbie  Blake  (NASA) 

Mission  Objectives: 

(1)  To  create  an  integrated  scientific  observing  system  that  will  enable 
multidisciplinary  study  of  the  earth’s  critical,  life-enabling,  interrelated 
processes  involving  the  atmosphere,  oceans,  land  surface,  polar  regions,  and 
solid  earth,  and  the  dynamic  and  energetic  interactions  between  them. 

(2)  To  develop  a  comprehensive  data  and  information  system  including 
a  data  retrieval  and  processing  system  to  serve  the  needs  of  scientists 
performing  an  integrated  multidisciplinary  study  of  planet  earth. 

(3)  To  acquire  and  assemble  a  global  database  emphasizing  remote 
sensing  measurements  from  space  over  a  decade  or  more  to  enable  definitive 
and  conclusive  studies  of  key  aspects  of  earth  system  science. 

(4)  To  improve  predictive  models  of  the  earth  system  that  involve 
interaction  of  system  components  such  as  air- sea  coupling  or 
biospheric/climate  interactions.  A  longer  term  goal  only  attainable  if  the 
other  objectives  are  successfully  accomplished. 

EOSDIS  version  0  will  be  available  July  1994  as  a  working  prototype  to  the 
science  community — will  not  be  open  to  outside  users  at  this  time.  It 
provides  a  uniform,  system-wide  information  one-stop  search  and  order 
function  to  access  the  data  collections  at  the  eight  Distributed  Active  Archive 
Centers  (DAACs)  (includes  legacy  systems  data,  near-term  non-EOS  space 
flight  data,  and  NASA/NOAA  pathfinder  datasets).  It  provides 
interoperability  among  heterogeneous  data  inventories  at  the  DAACs: 
geographically  distributed,  different  hardware  and  software  platforms, 
different  relational  DBMSs,  discipline  specific  metadata  and  science  data. 
Prototype  will  include:  Wide  Area  Information  Servers  (WAIS)  distributed 
guide  information  server  under  development;  world  wide  web  hypertext 
capability;  and  X-mosaic  (X  widgets  to  be  integrated  into  IMS  GUI).  Access 
to  other  Federal  agency  and  International  Earth  Science  data  includes:  access 
to  all  global  change  data  sets;  future  interchange  with  Oak  Ridge  NL,  NOAA, 
CIESIN/SEDAC,  and  CEOS  Inventory  Interoperability  Experiment.  EOSDIS 
Version  0  IMS  interoperability  includes  chosing  a  catalog  Working  Group 
Level  from  3  interoperability  models:  user  inte  dace  uses  common  set  of 
keywords  and  valid  values  for  searching  data  systems;  use  message  passing 
software  for  communication  among  data  systems;  or  at  each  DAAC  develop  a 
mapping  layer  that  translates  key  word  names  and  key  word  values. 

DAACs  are  looking  into  converting  data  into  Hierarchical  Data  Format 
(HDF)  for  distribution  (decided  on  HDF  because  there  is  more  HDF  software 
available  than  for  other  standards).  For  the  Global  Change  Master  Directory, 
they  developed  a  client  that  searches  against  the  Directory  and  returns  the 
answer  in  DIF  format. 
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Future  EOS  versions  will  manage  data  collected  from  EOS  spacecraft  also. 

(3)  Developments  in  spatial  data  standards:  Mr.  Dave  Danko  (DMA) 
Geospatial  data  is  information  defined  by  precise  geographic  location  and 
descriptive  attributes. 

Geospatial  data  standards  are  defined  conceptual  and  physical  models 
allowing  the  exchange  and/or  utility  of  geospatial  data.  A  geospatial  data 
standard  is  a  coherent  structure  to  support  measurement,  mapping, 
monitoring,  modeling,  terrain  evaluation,  and  spatial  reasoning  applications. 
There  are  two  basic  geospatial  structures:  vector  and  raster.  Commonly  used 
vector  formats/products  are  DFAD  (Digital  Feature  Analysis  Data,  SLF 
(Standard  Linear  Format),  DLG  (Digital  Line  Graph),  and  TIGER. 

Commonly  used  raster  formats/products  are  ADRG,  DTED,  LANDSAT,  AND 
SPOT. 

There  are  two  geospatial  data  exchange  standards:  DIGEST  (Digital 
Geographic  Information  Exchange  Standard)  and  SDTS  (Spatial  Data 
Transfer  Standards).  SDTS  is  general  and  provides  a  standardized  tool-kit  of 
formats  and  structures  out  of  which  one  can  construct  an  exchange  profile. 
The  onus  is  placed  upon  the  user  to  be  able  to  decipher  any  particular 
dataset.  By  creating  a  profile,  a  general  format  becomes  a  defined  format. 
DIGEST  is  a  defined  standard  providing  a  small  number  of  choices  for  the 
structuring  and  encoding  of  data.  For  one  class  of  data,  one  unique  way  of 
structuring  the  data  is  provided.  The  onus  is  placed  on  the  sender  to  organize 
his  data  so  that  it  fits  within  the  more  narrow  defined  constraints  of  the 
format.  SDTS  can  be  viewed  as  a  large  pipe  (general  format)  and  DIGEST  as 
a  narrow  pipe  (defined  format).  In  theory  the  narrow  pipe  can  fit  within  the 
large  pipe.  However,  DIGEST  components  may  directly  align  with  equivalent 
SDTS  components  when  a  SDTS  profile  is  developed  but  there  may  be  minor 
incompatibilities  due  to  terminology,  use  of  different  ISO  and  ANSI 
standards,  or  differences  in  the  feature  catalogs.  The  SDTS  data  dictionary  is 
used  to  construct  a  catalog  where  DIGEST  provides  an  internationally  coded 
catalog  (FACC). 

DIGEST  is  a  "defined”  format  developed  by  the  military  mapping 
organizations  of  11  NATO  nations  for  the  exchange  of  common  digital 
production  datasets  between  agencies.  For  one  class  of  data  one  unique  way 
of  structuring  data  is  offered.  DIGEST  has  a  family  of  defined  formats  for 
RASTER,  MATRIX,  and  VECTOR  data  found  in  Annex  A  -  ISO  8211 
(Archival),  Annex  B  -  ISO  8824  (Telecommunication),  and  Annex  C  - 
Georelational  (direct  utilization).  DIGEST  is  used  for  the  exchange  of  data 
within  the  members  of  the  Digital  Geographic  Information  Working  Group 
(DGIWG)  and  is  used  in  the  production  of  geodetic,  geographic,  geological  and 
geophysical  information.  The  DIGEST/Vector  Product  Format  (VPF)is  a 
user-oriented  direct  access  product  format  developed  by  DMA  as  a  MILSTD 
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and  used  in  Digital  Chart  of  the  World  (DCW),  Digital  Nautical  Chart  (DNC) 
and  Vector  Smart  Map  (VMAP). 

SDTS  (FIPS  173)  is  the  US  National  standard  for  exchange  of  spatial  data. 

As  a  “general”  format  for  the  exchange  of  arbitrary  data  sets,  it  provides  the 
capability  to  fit  a  very  broad  range  of  data  into  its  conceptual  model.  It 
provides  choices  so  that  the  data  collector  or  generator  can  define  which 
classes  of  phenomena  are  of  interest  and  which  spatial  objects  and 
relationships  should  be  used.  SDTS  has  transfer  module  formats  for 
VECTOR  and  RASTER  data  types  carried  in  ISO  8211  encoding.  SDTS  as  of 
February  1994  is  the  US  required  (mandatory)  standard.  It  is  not  intended  to 
facilitate  product  distribution  of  spatial  data  in  a  form  designed  for  direct 
access. 

In  examples  of  DIGEST  and  SDTS  data  models,  Danko  showed  that  they  are 
not  that  dissimilar.  DIGEST  has  pointers  back  to  higher  level  indices  and 
the  SDTS  spatial  object  has  pointers  to  a  composite  data  object  made  up  of 
feature  objects. 

OMB  Circular  A-16  established  the  Federal  Geographic  Data  Committee 
(FGDC)  of  fourteen  departments  and  agencies  to  promote  the  coordinated 
development,  use,  sharing  and  dissemination  of  surveying,  mapping,  and 
related  spatial  data.  Subcommittees  include:  base  cartographic,  cadastral, 
geodetic,  ground  transportation,  wetlands,  bathymetric,  cultural  and 
demographic,  geologic,  soils,  and  water.  The  National  Spatial  Data 
Infrastructure  (NSDI)  is  concerned  with  determining  what  data  exists,  access 
to  data,  and  identification  of  needs  for  and  generation  of  digital  data  of  value 
to  users.  The  FGDC  standards  WG  is  concerned  with  developing  content 
standards  for  spatial  metadata.  The  metadata  will  be  available  via  internet 
utilizing  WAIS  software.  The  spatial  metadata  content  includes: 
identification  information,  contact  information,  transfer  information,  status 
information,  source  information,  metadata  reference,  processing  history,  data 
quality  information,  entity/attributed  information,  and  coordinate 
information.  The  initial  draft  was  sent  out  in  Sept  92  to  government, 
industry,  and  academia  and  comments  returned  April  1993.  A  new  draft  will 
be  available  in  August  93  and  has  been  provided  to  DISA  who  is  reviewing 
elements  in  accordance  with  8320.1-M-l. 

Other  related  efforts  are:  MC&G  data  administration  which  is  to  develop  a 
cadre  of  information  modelers,  develop  a  detailed  data  model  and  elements 
with  a  DMA  product  using  the  DIGEST  FACC,  provide  model  to  JDBE  for 
SAI  modeling,  and  submit  group  of  MC&G  data  elements  into  the  DoD 
approval  process.  DMSO  Terrain  Requirements  and  Standards  Project  is 
DMSO  supported  and  has  collected  information  from  154  questionnaires  for 
analysis. 

Col  Rich  Johnson,  Chief  DMA  TIJ  (703-285-9238)  reported  on  Joint  MC&G 
Interoperability  and  the  DMA  mission  in  standardization  per  DoDD  5105.40. 
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DMA  is  the  PM  for  DoD  MC&G  and  prepares,  coordinates,  and  issues  MC&G 
specifications  and  standards,  and  guides  DoD  Components  to  ensure 
standardization  and  interoperability  of  systems  that  use  MC&G.  New 
organizations  that  have  formed  since  April  1993  include  MC&G  Joint 
Interoperability  Board  (MJIB)  and  the  Geospatial  Standards  Mgt  Committee 
(GSMC). 

The  MJIB  is  a  flag  level  advisory  board  chartered  and  chaired  by  Director, 
DMA  with  members  from  ASD  C3I,  JS,  Agencies  and  Offices,  Military 
Departments,  Joint  Command,  US  Coast  Guard,  JDG-CE  and  associate 
members  from  NOS  (NOAA)  and  USGS.  Its  current  tasks  include:  multiple 
raster  format  issues  (e.g.,  compression  for  joint  use),  CTAPS  mapping 
support,  and  how  to  support  Air  Force  Common  Mapping  Support  for  joint 
use,  and  in  future  digital  imagery  standards  and  MC&G,  preliminary  MC&G 
standards  hierarchy,  domestic  and  international  MC&G  standardization, 
MC&G  support  to  M&S,  MC&G  data  element  standardization,  and  digital 
MC&G  products  for  review. 

The  GSMC  is  a  0-4/0-5  level  working  group  formerly  the  SRAG.  It  supports 
the  MJIB  and  fits  as  the  former  MC&G  SMC  under  the  Standards 
Coordinating  Committee  (DISA  and  MCEB)  and  is  chaired  by  a  DMA  0-6. 

DMA  is  undergoing  a  paradigm  shift.  In  order  to  keep  combat  support 
relevant  to  the  nation  and  its  warriors  in  the  21st  century,  DMA  must 
reorient  from  manufacturing  specific  “products”  to  correlating  and  managing 
“Global  Geospatial  Information  and  Services  (G2IS)”.  DMA  view  now  is  that 
part  of  development  is  to  identify  applications  that  need  to  be  developed  (e.g, 
three  dimension  perspective  views)  and  will  go  out  and  solicit  products  and 
evaluate,  select,  and  standardize  on  best  one.  The  software  modules  will  be 
in  reusable  packages  and  distributed  through  DISA. 

(4)  Project  2851  Standards  Simulator  (Digital)  Data  Base  Program: 
Major  Kent  Johnson  (AST/YTMS) 

Program  objectives  are  to  reduce  development  redundancy  and  cost,  decrease 
schedule  and  performance  risk,  and  improve  database  correlation  between 
training  systems.  This  is  a  tri-service  sponsored  program  with  AF  lead  and 
strong  DMSO  support  and  its  objective  is  to  produce  high  fidelity  images  for 
use  in  realtime  aircraft  simulators  with  refreshes  60  times/second. 

The  original  concept  was  to  move  source  data  to  a  production  site  where  data 
was  produced  in  a  Generic  Transformed  Data  Base  (GTDB  MIL-STD  1820, 17 
Dec  92)  format  for  use  in  simulators.  Revised  concept  is  to  move  source  data 
to  library/production  facility  where  data  is  produced  in  GTDB  format  for  use 
in  simulators  and  for  simulators  to  send  data  in  standard  interface  format 
(SIF  MIL-STD  1821, 17  Jun  93)  back  to  library/production  facility  to  store  in 
library.  Facility  operations  are  scheduled  to  begin  in  1994.  DMA  will  provide 
and  manage  the  physical  facility  which  will  be  funded  by  services  and 
operated  by  a  contractor. 
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The  objective  is  to  develop  reusable  databases  that  can  be  shared  across  DoD 
training  programs.  The  standard  simulator  database  (SSDB)  terrain  culture 
as  of  July  1993  consists  of:  5  cells  Mac  corridor,  4  cells  San  Francisco  area,  10 
cells  Wyoming,  4  cells  Fallon  Nevada,  2  cells  China  Lake,  4  cells  Hunter 
Liggett,  8  cells  San  Diego/Yuma,  3  cells  Ft.  Rucker. 

The  system  products  are  GTDB,  and  SIF  for  high  detail  input/output 
(SIF/HDI).  SIF/HDI  data  formats  include  gridded  terrain  (3D),  vector  map 
features  and  attributes,  constructive  solid  geometry  (CSG)  and  polygons,  and 
imagery  with  photo- texture.  There  are  area  blocks  at  multiple  levels  of 
detail.  Visual,  radar,  FLIR,  NVG,  and  EO  datasets  are  supported.  The  active 
library  maintains  a  cumulative  database  of  the  best/current  data,  and  it 
validates  and  merges  selected  data  with  the  SSDB.  The  passive  library 
stores  validated  input/output  tapes  and  allows  users  to  get  exact  copies  of 
existing  databases.  They  have  limited  production  to  create  library  content 
from  charts,  DMA  products,  USGS,  photos,  imagery,  etc.  and  estimate  they 
can  produce  200  geo-cells  per  year  of  level  1  type  data. 

GTDB  is  an  output  product  tailored  only  for  specific  image  generators  and/or 
applications  (e.g.,  pilot  cockpit).  Its  tailoring  includes:  min/max  number  of 
polygons/edges,  LOD,  area,  models,  coordinate  system,  convex  polygons,  etc. 
SIF  is  both  input  and  output  format,  is  system  independent  and  closely 
represents  SSDB  contents.  Data  formats  for  SFI/HDI  include  model 
geometry  (up  to  nine  levels  of  detail  per  model),  model  attributes,  model  type 
(2D  static  for  surface  models,  3D  static  for  objects  fixed  on  terrain,  and  3D 
dynamic  for  moving/articulated  objects);  culture  geometry,  culture  attributes, 
culture  geometry  types,  culture  geometry  primitives,  gridded  terrain/texture 
geometry,  gridded  terrain/texture  attributes,  texture  sources,  and  texture 
libary  stages. 

Question  about  3D  model  Answer:  no  scripted  positioning,  the  database 
supports  movement  but  the  application  has  to  manage  this. 

(5)  Dynamic  Environment  and  Terrain  Modeling  in  DIS:  Jeff  Turner 
(Army  TEC) 

The  project  objective  is  to  support  dynamic  environment  and  terrain  in  DIS 
by  developing  DoD  standard  physics-based  software  models,  DIS  protocols, 
and  DIS  graphic  rendering  techniques.  Primary  sponsor  is  DMSO,  the 
Program  Manager  is  STRICOM  and  the  team  players  include  USATEC  (Lorel 
and  Grumman),  USAES,  USAWES,  NPGS,  USAF  Phillips  Lab  (TASC).  They 
are  modeling  mobility  of  vehicles,  dynamic  terrain  and  obscurants.  For 
enhanced  mobility  models  they  use  DMA  Interim  Terrain  Data  (ITD)  support 
and  ITD(SIF)  format  data  importer  for  mobility  model  synthesis.  Dynamic 
terrain  models  support  cratering,  berm  penetration,  defilade  positioning, 
berm  construction,  and  rut  creation.  Obscurants  will  include  battlefield 
smoke,  atmospheric  cumulus  and  stratiform  clouds,  atmospheric  fog  and 
haze,  vehicle  dust,  and  fire  and  explosions.  They  are  using  Computer  Image 


1022 


Generator  Logical  Interface  Package  (CLIP)  to  provide  a  common  application 
programmer’s  interface  for  the  development  of  visual  applications.  Phase  I 
results  will  be  demonstrated  at  the  March  94  DIS  Conference  and  will  show  2 
networked  image  generators  showing  DIS  battlefield  smoke  and  atmospheric 
clouds  and  a  virtual  bulldozer  proof  of  concept.  Phase  II  will  be  demoed  in 
December  94  and  will  show  all  developed  models. 

The  major  issue  has  to  do  with  performance  in  supporting  dynamic  changes. 
The  target  platform  is  a  high-powered  Onyx  workstation:  10  frames/sec 
appears  to  be  ok  for  obscurants.  They  are  planning  to  pre-distribute 
data/information  about  the  atmosphere.  If  smoke  is  detonated  during  play, 
that  fact  will  be  sent  in  a  PDU  to  all  relevant  models  which  will  be  using  the 
same  atmospheric  model  for  dispersion. 

(6)  STRICOM  DIS  Standards  Initiatives:  Gene  Wiehagen  (STRICOM) 
Wiehagen  went  over  the  history  of  the  DIS  workshops  from  August  1989  to 
present  and  the  DIS  compliant  systems/programs.  DIS  working  groups  and 
subgroups  include:  communication  protocols,  interface,  time,  mission  control; 
emission;  simulation  management;  radio  communications;  communication 
architecture  security;  simulated  environment;  atmosphere;  land;  sea;  fidelity, 
exercise  control,  feedback  requirements;  and  field  instrumentation.  There 
are  many  international  participants  at  the  DIS  workshops.  Gene  went  over 
the  DIS  standardization  process — Chien  Huo  has  recently  written  a  paper 
that  shows  an  as-is  process  model  and  suggests  a  to-be  process  model  for  DIS 
standardization.  Wiehagen  also  has  a  list  of  the  DIS  1.0  PDUs,  of  the 
proposed  DIS  2.0  PDUs  (these  are  emission,  laser,  transmitter,  signal,  and 
simulation  management;  and  DIS  3.0  PDUs  (potential)  which  will  cover  C3I, 
dynamic  terrain,  weather/atmosphere,  fidelity  controls,  transfer  control, 
aggregate/disaggregate,  and  instrumentation.  DIS  regime  goes  from  high 
level  units  using  the  Aggregated  Level  Simulation  Protocol  (ALSP),  to 
platforms  using  DIS  protocol,  to  components  in  MODSIM,  to  parts  in  JMASS. 
The  regime  varies  in  time  from  the  aggregated  level  of  weeks  down  to 
microseconds  for  part  simulations. 

(7)  DIS  Fidelity  Issues:  John  Eisenhardt 

Though  not  on  the  schedule,  John  Eisenhardt  talked  about  DIS  fidelity 
issues.  Fidelity  needs  to  be  measured  in  the  context  of  the  application.  An 
asset  is  validated  for  a  designed  application  and  because  it  is  validated  does 
not  necessarily  mean  it  can  be  reused  in  DIS  applications  without 
revalidation.  There  is  a  a  database  catalog  of  DIS  components  and  their 
fidelity  but  there  is  a  need  to  look  at  overall  DIS  fidelity,  the  system  fidelity 
when  DIS  simulators  are  interconnected.  There  needs  to  be  a  hierarchy  of 
fidelity  domains  and  components  need  to  reference  those  domains,  include 
their  past  W&A  history  in  relation  to  how  they  were  used  in  DIS 
applications. 

(8)  Distributed  Interactive  Simulation  Standards  Process:  Chien 
Huo  (JIEO/DFS) 


1023 


Chien  discussed  the  DISA  JIEO  Center  for  Standards  (CFS)  and  what  they 
are  doing  to  give  program  support  to  DMSO  and  the  M&S  community.  In  the 
DMRD  918  Defense  Information  Infrastructure,  the  Information  Technology 
Standards  Program  Office  serves  as  the  mechanism  for  developing, 
specifying,  certifying,  adopting  and  enforcing  standards.  The  DISA  CFS  is 
the  executive  agent  for  DoD  information  standards  and  the  DISA/Joint 
Interoperability  Test  Center  (JITC)  is  the  executive  agent  for  information 
systems  testing.  DoD  spends  over  $50  billion  annually  on  information 
technology,  there  are  over  2000  IT  standards,  and  over  700  standards 
committees.  The  problem  is  that  most  DoD  standards  efforts  are  done  by 
individual  DoD  projects,  there  are  uncoordinated  “architectures”  and 
acquisitions  that  specify  conflicting  standards  and  the  process  for  enforcing 
compliance  is  embryonic.  The  new  order  for  preference  for  standards  are: 
international,  national,  federal,  and  military.  Chien  presented  a  map  of 
standard  thrusts  and  discussed  the  DIS  standards  initiative.  He  gave  a 
vision  of  the  Directorate  for  DoD  Standards  Assistance  as  a  one  stop  shop 
which  would  provide  open  systems  standards  and  profile  solutions  for 
architects,  engineers,  and  implementors. 

9.  DATA  STANDARDS  ACTIVITIES  IN  M&S  PROJECTS/PROGRAMS 

(1)  Re-utilization  and  Standardization  of  Moving  Models  in  Virtual 
Simulation:  Farid  Mamaghami  (PM-CATT,  IDA) 

Farid  provided  a  general  definition  of  a  model  as  a  filtered  representation  or 
instantiation  of  characteristics  and  attributes  associated  with  real  entities. 
Specific  to  his  brief  was  a  description  of  a  model  as  a  3-D  representation  of 
vehicles  (simulation  entities)  and  their  attributes  for  visual  and  sensor 
systems.  He  pointed  out  that  many  variations  of  the  same  “model”  exist 
among  DoD  programs  in  different  forms  and  what  is  needed  is  a  central 
repository  and  catalog  of  models  created  under  DoD  programs  (much 
agreement  from  all  of  us).  He  said  that,  for  example,  CAD  vendors  or 
individual  simulation  houses  provide  catalogs  of  their  existing  models  but 
catalog  formats  are  different  and  limited  in  capacity  to  carry  all  pertinent 
information  and  attributes.  He  believes  that  unlike  terrain  databases, 
models  are  easier  to  convert  and  interchange.  Challenges  to  re-utilization  are 
application  requirements  and  run-time  platform  capabilities  (e.g.,  simple  vs 
detailed  models,  texture  vs  geometry  detail,  collision  and  bounding,  data 
organization,  etc.).  He  recommended  that  DMSO  assess  the  value  for 
establishing  a  central  repository  and  catalog  capability,  establish  the 
technical  mechanism  for  access  and  distribution  of  data,  acquire  the  data  and 
organize  a  repository,  organize  the  library  based  on  category  of  use,  and 
within  each  category  organize  data  for  the  same  model  based  on  fidelity  and 
performance  use. 

(2)  Close  Combat  Tactical  Trainer  (CCTT)  update  and  data 
standards:  Rob  Wright  (CCTT/RCI) 

Combined  Arms  Tactical  Trainer  (CA1T)  Task  Data  Base  is  an  information 
system  developed  to  provide  battlefield  oriented  Collective  Task  data  to 
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software  engineer  development  teams.  The  CATT  approach  is  to  seamlessly 
integrate  text  (WordPerfect),  data  (FoxPro),  and  graphics  (PCX).  The  data 
sources  are:  ARTEP  manuals,  proponent  schools  information,  subject  matter 
expert’s  information,  and  field  manuals.  The  CATT  Task  Data  Base  is 
applicable  to  analyze  Collective  Tasks  as  they  apply  to:  training  development 
and  analysis,  trainng  manual  development  and  production, 
simulator/software  development  and  verification,  standardizing  Collective 
Tasks  of  the  ARTEPs,  and  comparing  TTPs  to  the  ARTEP  tasks.  The 
database  may  be  applicable  to  any  source  of  Collective  Task  data  in  any  of  the 
military  services.  CATT  Task  Data  Base  is  a  weapons’  performance  database 
and  one  of  its  uses  wil  be  to  be  able  to  validate  SAFOR  behaviors  by  seeing 
how  different  units  perform  comparable  tasks  and  then  to  reuse  behaviors  in 
other  similar  or  SAFOR  units.  They  plan  to  incorporate  short  videos  into  the 
database  so  a  programmer  can  see  how  the  object  operates. 

The  PM-CATT  Software  Initiatives  Program  was  briefed  by  Luci  Haddad. 

The  program  goals  are  to:  support  DoD  computing  infrastructure  and 
initiative  principles;  improve  interoperability,  productivity,  quality  and 
reliability;  and  reduce  costs.  The  program  consists  of  three  parts:  process 
improvement,  data  element  standardization,  and  asset  reuse  and  technology 
insertion.  They  have  used  IDEFO  to  show  the  process  flow  of  administrative 
papers,  etc.  to  satisfy  a  CCTT  CALS  requirement. 

(3)  Universal  Threat  System  for  Simulation:  Clay  Putman  (GPS  Tech 
supporting  Navy/UTSS) 

UTSS  is  the  joint  service  repository  for  DIA  approved  threat  data  and 
validated  real-time  simulation  software  used  as  standardized  input  to  DoD 
training  simulation  programs.  The  main  goal  of  UTSS  is  to  enhance  training 
and  improve  operational  readiness  while  significantly  reducing  acquisition 
and  support  costs.  Current  problems  include  lack  of  standards;  unvalidated 
data;  and  threat  models  are  recreated  with  each  new  simulation  acquisition. 
There  are  3  UTSS  efforts  to  address  these  problems:  (1)  creation  of  a 
universal  database;  (2)  consolidation  of  threat  simulations  into  a  threat 
simulation  library  where  they  can  be  reused;  and  (3)  developmental 
standards  for  data  and  simulations.  This  is  a  three-phased  effort:  phase  1  is 
requirements  analysis  (doing  this  now);  phase  two  is  design  synthesis;  and 
phase  3  wil  be  development. 

Currently  most  of  the  threat  data  is  for  air  crew  training  devices.  All  of  the 
data  has  to  be  validated  and  much  of  it  is  eight  years  old.  They  are 
establishing  two  working  groups:  database  (want  to  get  MITRE  and  RAND 
involved),  and  realtime  simulation  software. 

(4)  Data  Base  System  Upgrade  (DBSU)  Project:  Col  Rayford 
Eubahks(JS) 

DBSU  is  a  DMSO  funded  project  to  enhance  database  systems  developed  by 
USCENTCOM,  HQMC,  and  JWC  that  provide  data  for  M&S.  DBSU  allows 
for  sharing  of  capabilities  and  the  enhancement  of  tools  to  improve  and 
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expand  the  scope  of  data  available  to  joint  models.  DBSU  components  are: 
conventional  force  database  (CFDB),  master  simulation  data  base  (MSDB), 
data  quality  engineering  (DQE),  and  ancillary  database  (ADB)  which  expands 
model  data  with  parametric  data  such  as  weapon  parameters,  aircraft  and 
ship  characteristics.  The  objectives  are  to  apply  DQE  to  both  databases, 
build  an  ancillary  database  supplement  to  the  MSDS,  and  to  design  a 
graphical  user  interface  for  the  MSDS.  The  data  architecture  shows  the 
sources  (units,  personnel,  equipment,  DIA’s  DB)  coming  into  a  repository 
where  DQE  is  applied  and  from  there  being  entered  into  the  CFDB  where  it 
rfin  be  presented  to  the  end  user  as  16  ASCII  files  or  be  refined  for  the  MSDS 
(where  data  is  joined  with  JWC’s  ADB)  to  supply  models  such  as  JTLS,  CBS, 
TACWAR  and  JCM.  In  the  future  there  may  be  new  interfaces  to  other 
models. 

They  have  20  worldwide  joint  and  service  users.  The  Marine  Corps  currently 
does  quality  checks  on  their  databases.  The  database  has  over  500K  blocks  of 
data  in  a  fully  operational  system,  the  current  effort  is  just  to  enhance  the 
system.  Some  of  the  ancillary  databases  may  consist  of  open  data  like  data 
from  Jane’s. 

Some  of  their  user  problems:  simulation  variables  often  have  no  real  world 
source,  organizations  don’t  like  to  share  data,  many  models  provide  no 
training,  and  there  is  a  lack  of  advice  on  appropriate  models.  Solutions:  new 
models  where  the  data  issues  are  addressed  during  development  and  funding 
includes  both  training  and  data  sources,  for  existing  models  use  some  of  the 
current  funding  to  centralize  functions,  and  eventually  establish  an 
organization  that  provides  training  and  data  assistance  for  widely  accepted 
joint  models. 

(5)  Operation  Analysis  and  Simulation  Interface  System  (OASIS): 
LTC  Dan  Hogg  (JS/J8) 

The  OASIS  strategy  is  to  maintain  data  in  a  central  location  and  allow  widest 
access  possible  to  all  J-8  action  officers.  They  are  using  object-oriented  design 
and  have  built-in  verification  and  validation.  They  furnish  OASIS  data  to 
outside  sources  as  a  single  point  of  request  and  can  prepare  and  download 
data  to  be  sent  to  others.  The  system  runs  on  frontend  sun  workstations 
using  a  fileserver  and  backend  Vax  cluster.  They  are  running  Unix  with 
Ingres  on  the  Suns,  and  VMS  with  Ingres  on  the  Vax.  The  system  supports  a 
hierarchical  structure  from  folders  to  classes  to  object  lists  and  details.  The 
system  includes  access  control,  windows4GL  (point  and  click),  V&V,  data 
transfer,  data  editing,  on-line  help  and  event  tracking. 

Status:  They  are  at  IOC/milestone  III  but  are  having  system  performance 
problems  probably  due  to  the  network;  they  are  incorporating  conventional 
force  data;  and  creating  a  liaison  with  DIA  for  IDB  products.  Some  concerns 
are  with  continually  changing  requirements;  the  resources  required  for  data 
modeling  using  IDEF1X,  security  considerations  with  interoperability  and 
incorporation  of  MLS  technology  (how  to  change  legacy  OASIS  system  to  use 
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new  security  technology);  and  with  performance  issues.  An  agenda  topic  for 
the  upcoming  mobility  conference  is:  whether  there  is  an  IDEF  process  and 
data  model  for  mobility  data  and,  if  not,  then  will  there  be  one. 

(6)  Joint  Data  Base  Element  (JDBE)  experience  with  developing 
subject  area  information  models:  Peter  Valentine  (Army/EPG) 

JDBE  status:  the  JDBE  methodology  paper  and  methodology  assessment 
white  paper  have  been  published;  the  JDBE  military  handbook  is  available  in 
draft  form,  the  subject  area  information  model  for  radio  frequency  spectrum 
design  is  complete,  and  the  data  repository  design  is  completed  and  the 
repository  is  being  populated.  The  JDBE  Military  Handbook  explains  the 
JDBE  process,  gives  step-by-step  directions  c.<»  how  to  proceed  and  the 
appendices  for  the  first  SAI  model  in  radio  frequency  spectrum  will  be 
published  separately.  The  data  dictionary/directory  is  in  electronic  form  on 
PC-based  software  and  contains  standard  data  element  and  entities  with 
mapping  between  the  entities  and  elements  and  traceabilty  to  project 
databases. 

Lessons  learned:  interest  in  data  modeling  is  high;  demand  for  training  is 
high;  resources  for  project  modeling  are  limited;  reverse  engineering  from 
databases  and  other  non-data  modeling  standards  efforts  is  doable;  subject 
matter  expert  participation  is  critical;  understanding  of  scope,  frame  of 
reference,  and  level  of  abstraction  is  important  but  may  not  be  good  enough 
for  M&S;  and  there  are  risks  in  pushing  the  technology.  The  project  models 
used  in  the  JDBE  SAI  model  were:  CROSSBOW,  ECASC,  ECE  threat, 
EMETF  DBR,  EWIR,  MUES,  RASPUTIN,  and  TEARS,  There  were  three 
views:  antenna,  RF  signal,  RF  equipment  each  with  a  different  number  of 
entities  but  about  the  same  number  of  attributes.  They  gave  an  example  of 
the  issue  with  modeling  different  levels  of  abstraction  between  an  antenna 
model  and  an  antenna  model  with  an  antenna  pattern. 
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10.  SUMMARY  AND  WRAPUP:  DR.  CHEIN  HUO  (JIEO/CFS) 

(1)  Guidance:  we  could  take  guidance  from  this  meeting  in  the  data  modeling 
area:  use  the  integration  of  the  DoD  Enterprise  Model  with  the  ATCCIS 
Generic  Hub  Data  Model  to  develop  bottom-up  (or  middle-up_  interim  data 
models. 

(2)  Change  in  I/DB  meeting  structure:  discussed  whether  the  next  meeting 
should  be  handled  as  a  short  general  session  and  then  break  the  group  up 
into  working  groups?  The  consensus  was  to  keep  it  the  way  it  is,  as  one 
general  session.  But  people  would  like  to  see  some  special  sessions  like  one 
on  data  modeling,  and  Howard  Haeker  would  like  to  see  a  session  on  sources 
of  data. 

(3)  Need  to  define  types  of  data  in  databases.  We  may  need  to  collect 
information  about  databases  and  then  try  to  determine  types  from  the 
information  collected.  Ken  Kaufman  said  that  we  need  to  try  to  get  database 
information  from  the  services. 

(4)  There  is  also  a  need  to  define  the  terminology  we  use  and  develop  a 
lexicon  so  we  are  all  talking  the  same  language. 

(5)  W&C:  need  to  look  at  how  to  get  to  the  operational  data  gathered  by 
users  and  use  these  as  part  of  the  validation  process 

(6)  People  asked  for  an  overview  of  DMSO  in  terms  of  who  they  are  funding 
to  do  what 

(7)  Suggestion  that  the  I/DB  form  seme  working  groups  (See  Section  4). 

(8)  Data  reconciliation  is  an  issue  that  hasn’t  been  addressed:  what  does  one 
do  with  overlapping  data? 

(9)  If  there  are  difficulties  with  the  standardization  process,  what  might 
alternatives  to  standard  data  elements  be? 
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F.  ACRONYMS 


A3H7 

ADDs 

ADMIN 

AF 

AFC4A 

AFSAA 

AJTSH 

AMSAA 

AMSMO 

API 

ARL 

ARMs 

ARRIIPS 

ARTBASS 

ASC 

ASN.l 

ATRIS 

AVCATT 

BDS-D 

BFTT 

BLOB 

C3I 

CAGIS 

CATT 

CCTT 

CDIF 

CDTF 

CENTCOM 

CFDB 

CFS 

CIM 

CNA 

CNO 

COE 

COEAs 

CONOPS 

CSC 

DA 

DB 

DBMS 

DDN 

DDR&E 

DDRS 

DE 


Name  of  a  CDIF  working  group  OME/A3H7 
Army  Data  Dictionary 
Administration 
Air  Force 

Air  Force  Command,  Control,  Communications,  and 

Computers  Administration 

Air  Force  Studies  and  Analysis  Agency 

Name  of  a  data  base 

Army  Material  Systems  Analysis  Activity 

Army  Model  and  Simulation  Office 

Application  Program  Interface 

Advanced  Research  Laboratory 

Automated  Repository  for  Models  and  Simulations 

A  database  used  by  TECNET 

A  terrain  database  being  used  by  a  RAND  project 

An  organization 

Abstract  Syntax  Notation.  1 

A  database  used  by  TECNET 

Avionics  Combined  Arms  Tactical  Trainer 

Battle  Field  Distributed  Simulation  Demonstration 

Battle  Fleet  Tactical  Trainer 

Binary  Large  Objects 

Command,  Control,  Communications  and  Intelligence 

Cartographic  and  Geographic  Information  System 

Combined  Arms  Tactical  Trainer 

Close  Combat  Tactical  Trainer 

CASE  Data  Interchange  Standard 

Complex  Data  Task  Force 

Central  Command 

Conventional  Force  Data  Base 

Center  For  Standards 

Center  for  Information  Management  or  Corporate 

Information  Management 

Center  for  Naval  Analysis 

Center  for  Naval  Operations 

Common  Operating  Environment 

Cost  and  Effectiveness  Analysis 

Concept  of  Operations 

Name  of  a  Company 

Data  Administration 

Data  Base 

Date  Base  Management  System 
Defense  Data  Network 

Director  Development,  Research,  and  Engineering 
Defense  Data  Repository  System 
Data  Element 
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DFAD 

DIA 

DISA 

DMA 

DMSO 

DQE 

DSNET 

DTED 

DTIC 

DUSA 

DoD 

DoDD 

E2DIS 

ECDB 

ECM 

EPG 

EPL 

ERX 

EWIR 

EXCIMS 

EXCOM 

FACC 

FDAd 

FDTS 

FFRDC 

FGDC 

FIPS 

FPI 

FY 

GCCS 

GPS 

GUI 

HQ 

IC 

ICP 

IDA 

IDEF 

IDL 

IGES 

IM 

INNET 

IRDS 

ISA 

ISC 

ITD 

ITF 

JCM 

JCS 

JDBE 


Digital  Feature  Analysis  Data 
Defense  Intelligence  Agency 
Defense  Information  Systems  Agency 
Defense  Mapping  Agency 
Defense  Modeling  and  Simulation  Office 
Data  Quality  Engineering 
Defense  Secure  Network 
Digital  Terrain  Elevation  Data 
Defense  Technical  Information  Center 
Deputy  Under  Secretary  of  the  Army 
Department  of  Defense 
Department  of  Defense  Directive 

Environmental  Effects  Distributed  Interactive  Simulation 

Equipment  Characteristics  Data  Base 

Electronic  Counter  Measures 

Army  organization 

A  database  used  by  TECNET 

Name  of  IDEF1X  tool:  ERwin/ERX 

A  database  used  by  TECNET 

Executive  Council  for  Models  and  Simulations 

Executive  Committee 

Feature  Attribute  Coding  Catalog 

Functional  Data  Administrator 

Federal  Data  Transfer  Standard 

Federally  Funded  Research  and  Development  Center 

Federal  Geographic  Data  Committee 

Federal  Information  Processing  Standard 

Functional  Process  Improvement 

Fiscal  Year 

Global  Command  and  Control  System 

Global  Positioning  System 

Graphical  User  Interface 

Headquarters 

Intelligence  Community 

Information  Class  Proponent 

Institute  for  Defense  Analysis 

Integrated  Computer-Aided  Definition  Language 

Interchange  Definition  Language 

Initial  Graphics  Exchange  Specification 

Information  Management 

A  database  used  by  TECNET 

Information  Resource  Dictionary  System 

A  company  name 

Information  Systems  Command 

Interim  Terrain  Data 

Infrastructure  Task  Force 

Name  of  a  model 

Joint  Chiefs  of  Staff 

Joint  Data  Base  Elements  (project) 
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JHU 

Johns  Hopkins  University 

JIEO 

Joint  Interoperability  Engineering  Organization 

JITC 

Joint  Interoperability  Test  Center 

JMA 

Data  used  by  ARMS  project 

JMASS 

Joint-Modeling  and  Simulation  System 

JOPES 

Joint  Operation  Planning  and  Execution  System 

JS 

Joint  Staff 

JTAD 

Joint  Test  Asset  Database 

JTLS 

Joint  Theater  Level  Simulation 

JUDI 

Joint  Universal  Data  Interpreter 

LRPS 

A  database  used  by  TECNET 

LSAR 

A  database  used  by  CCTT 

M&S 

Modeling  and  Simulation 

MC&G 

Mapping,  Charting,  and  Geodesy 

MCEB 

Military  Communications  Electronics  Boards 

MICOM 

Missile  Command 

MIIDS 

Military  IntelUgence  Integrated  Data  System 

MISIC 

A  DIA  organization 

MLS 

Multi-Level  Security 

MORS 

Military  Operations  Research  Society 

MSDS 

Master  Simulation  Data  System 

MSTIRC 

A  database  used  by  TECNET 

MTFs 

Message  Text  Formats 

NASC 

Navy  organization 

NAVINTCOM 

Navy  organization 

NAVOCEANO 

Navy  organization 

NAVSEA 

Navy  organization 

NCCOSC 

Navy  organization 

NERF 

A  database  used  by  TECNET 

NID 

A  database  used  by  TECNET 

NIST 

National  Institute  of  Standards  and  Technology 

NL 

Naval  Laboratory 

NRL 

Navy  Research  Laboratory 

NRaD 

Navy  Research  and  Development 

NSA 

National  Security  Agency 

NSTDB 

A  NWTDB  database 

NVWC 

A  Navy  organization 

NWTDB 

Navy  Warfare  Tactical  Data  Base 

OCEANCOM 

A  Navy  organization 

OME 

A  name  of  a  CDIF  working  group 

OPNAV 

A  Navy  Organization 

ORG 

Organization 

OSD 

Office  of  the  Secretary  of  Defense 

OTECC 

A  database  used  by  TECNET 

PA&E 

Program  Analysis  and  Evaluation 

PCTE 

Portable  Common  Tools  Environment 

PDU 

Protocol  Data  Unit 

PEGASYS 

A  system 

PH 

Probability  Hit 
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PK 

Probability  Kill 

POC 

Point  of  Contact 

PRC 

Name  of  a  corporation 

PVDB 

Database  from  PEGASYS 

RCI 

Name  of  a  corporation 

RDBMS 

Relational  Data  Base  Management  System 

RFP 

Request  For  Proposal 

RLF 

Reuse  Library  Framework 

SDE 

Standard  Data  Element 

SID 

Systems  Information  Directory 

SIF 

Standard  Interchange  Format 

SIMDAT 

Simulation  Data 

SIMVAL 

Simulation  Validation 

SML 

Standard  Markup  Language 

SOCOM 

Special  Operations  Command 

SPAWAR 

A  Navy  organization 

SQL 

Standard  Query  Language 

SR 

Software  Reuse 

SSDC 

Space  System  Development  Center 

STANAG 

Standard  Agreement 

STRICOM 

Simulation  Training  and  Instrumentation  Command 

SYNETICS 

Name  of  a  company 

SYSCOM 

A  Navy  organization 

T&E 

Test  and  Evaluation 

TACWAR 

Name  of  a  simulation  model 

TADILS 

Tactical  Data  Information  Link 

TAFIM 

Technical  Architecture  Framework  for 

Information  Management 

TECHMATES 

Name  of  a  company 

TECNET 

Technical  Network  for  the  Test  and  Evaluation  Community 

TESTFACS 

A  database  used  by  TECNET 

TEXIS 

A  TECNET  database 

TF 

Task  Force 

TRAC 

Training  Command 

TRADOC 

Training  and  Doctrine  Command 

TSD 

Name  of  an  organization 

TWSTIAC 

Name  of  an  Information  Analysis  Center  that  Supports  M&S 

UCF 

University  of  Central  Florida 

UNISYS 

Name  of  a  company 

USAEPG 

Name  of  an  Army  organization 

USCENTCOM 

U.S.  Central  Command 

UTM 

Universal  Transverse  Mercator 

UTSS 

Universal  Threat  System  for  Simulators 

V&V 

Verification  and  Validation 

VDS 

A  company  name 

VMS 

VAX  operating  system 

VPE 

Visual  Programming  Environment 

W&A 

Verification,  Validation  and  Accreditation 

W&C 

Verification,  Validation  and  Certification 
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WAIS 

WARSIM 

WG 

WWW 

X3H4.1 

X3L8 

XOMT 


Wide  Area  Information  Server 

A  simulation  model 

Working  Group 

World  Wide  Web 

ANSI  working  group 

ANSI  working  Group 

Air  Force  M&S  Organization 


